Firebase Security rules to restrict access on all paths but one?












1















Question:



For the different top-level firestore collections below, how to restrict access to all but one of the paths?




We are building a data schema in Firestore to support a chat app for teachers across multiple schools.



The top-level firestore collections include:




  • /siteAdminUsers

  • /schools

  • /schools/{schoolId}/teachers

  • /schools/{schoolId}/chats


Below is the security rules setup we are trying now - where we check for:




  1. valid user auth

  2. expected value exists in userClaim variable request.auth.token.chatFlatList


However, the read listener for /messages is being blocked.




Error message:



FirebaseError: [code=permission-denied]: Missing or insufficient permissions






service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null
&& request.auth.token != null
&& request.auth.token.chatFlatList.val().contains($discussionId);
}
}




Details



We are using cloud functions for all data read/write, so for almost every case we can just block all client access.



The one exception is for the chat discussions, where we need to set a snapshot listener in the mobile client to know when there are new messages.



Sub-collection notes:



At a school, there are discussion sessions for school staff (teachers, admins, etc)



/schools/{schoolId}/chats/{discussionId}


Where each discussion-document contains:




  1. list of participant teacher ids

  2. subcollection for actual messages where each document is an indivual posted message:


/schools/{schoolId}/chats/{discussionId}/messages



User Claim code from Cloud Function



Looking at the cloud function logs, we have verified that the userClaim is being set.



return firebaseAdmin
.auth()
.setCustomUserClaims(
uid, {
chatFlatList: 'id1 id2 id3'
}
);


UPDATE #1



Tried the following variation where rules skip/omit the check on userClaim and auth.token.



However, still same permission error.



service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null;
}

}
}









share|improve this question
























  • Have you tried simply allowing all access to messages, just to see if the problem is specifically with the interpretation of chatFlatList?
    – Doug Stevenson
    Nov 13 '18 at 3:26










  • @Doug, post is updated with listing for trying rules setup as you descibe. I was wondering - is it maybe that the main "global rule" match /{document=**} , somehow overwrites the custom rule for messages? I was trying to find something in the docs that explains if at least 1 rule is matched for true, then that is enough .. not sure if I missed that detail, but didn't see it. Thanks
    – Gene Bo
    Nov 13 '18 at 3:39












  • You can reject the entire database like that, then allow specific parts. It's totally doable. You just can't allow some part of the database, then reject it later. Once allowed, always allowed for that user.
    – Doug Stevenson
    Nov 13 '18 at 4:21






  • 1




    Since firebase console asks for feedback - on this point I would just like to take the opportunity to say: Overall the different Firebase tiers have been straight fwd to ramp up on and work with. But - respectfully (big Firebase advocate here!) - security rules area has been the most cumbersome (not so intuitive) to navigate/manage. E.g. no real way to debug errors in the rules logic it seems. Simulator doesn't support debug logs to determine which rule is matching for true or false, nor allows userClaim cfgs. Either the rules cfg works or it doesn't :(. Any guidance, very apprect'd :). Thanks
    – Gene Bo
    Nov 15 '18 at 2:21












  • I understand, these are issues that people at Firebase are thinking about.
    – Doug Stevenson
    Nov 15 '18 at 3:11
















1















Question:



For the different top-level firestore collections below, how to restrict access to all but one of the paths?




We are building a data schema in Firestore to support a chat app for teachers across multiple schools.



The top-level firestore collections include:




  • /siteAdminUsers

  • /schools

  • /schools/{schoolId}/teachers

  • /schools/{schoolId}/chats


Below is the security rules setup we are trying now - where we check for:




  1. valid user auth

  2. expected value exists in userClaim variable request.auth.token.chatFlatList


However, the read listener for /messages is being blocked.




Error message:



FirebaseError: [code=permission-denied]: Missing or insufficient permissions






service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null
&& request.auth.token != null
&& request.auth.token.chatFlatList.val().contains($discussionId);
}
}




Details



We are using cloud functions for all data read/write, so for almost every case we can just block all client access.



The one exception is for the chat discussions, where we need to set a snapshot listener in the mobile client to know when there are new messages.



Sub-collection notes:



At a school, there are discussion sessions for school staff (teachers, admins, etc)



/schools/{schoolId}/chats/{discussionId}


Where each discussion-document contains:




  1. list of participant teacher ids

  2. subcollection for actual messages where each document is an indivual posted message:


/schools/{schoolId}/chats/{discussionId}/messages



User Claim code from Cloud Function



Looking at the cloud function logs, we have verified that the userClaim is being set.



return firebaseAdmin
.auth()
.setCustomUserClaims(
uid, {
chatFlatList: 'id1 id2 id3'
}
);


UPDATE #1



Tried the following variation where rules skip/omit the check on userClaim and auth.token.



However, still same permission error.



service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null;
}

}
}









share|improve this question
























  • Have you tried simply allowing all access to messages, just to see if the problem is specifically with the interpretation of chatFlatList?
    – Doug Stevenson
    Nov 13 '18 at 3:26










  • @Doug, post is updated with listing for trying rules setup as you descibe. I was wondering - is it maybe that the main "global rule" match /{document=**} , somehow overwrites the custom rule for messages? I was trying to find something in the docs that explains if at least 1 rule is matched for true, then that is enough .. not sure if I missed that detail, but didn't see it. Thanks
    – Gene Bo
    Nov 13 '18 at 3:39












  • You can reject the entire database like that, then allow specific parts. It's totally doable. You just can't allow some part of the database, then reject it later. Once allowed, always allowed for that user.
    – Doug Stevenson
    Nov 13 '18 at 4:21






  • 1




    Since firebase console asks for feedback - on this point I would just like to take the opportunity to say: Overall the different Firebase tiers have been straight fwd to ramp up on and work with. But - respectfully (big Firebase advocate here!) - security rules area has been the most cumbersome (not so intuitive) to navigate/manage. E.g. no real way to debug errors in the rules logic it seems. Simulator doesn't support debug logs to determine which rule is matching for true or false, nor allows userClaim cfgs. Either the rules cfg works or it doesn't :(. Any guidance, very apprect'd :). Thanks
    – Gene Bo
    Nov 15 '18 at 2:21












  • I understand, these are issues that people at Firebase are thinking about.
    – Doug Stevenson
    Nov 15 '18 at 3:11














1












1








1








Question:



For the different top-level firestore collections below, how to restrict access to all but one of the paths?




We are building a data schema in Firestore to support a chat app for teachers across multiple schools.



The top-level firestore collections include:




  • /siteAdminUsers

  • /schools

  • /schools/{schoolId}/teachers

  • /schools/{schoolId}/chats


Below is the security rules setup we are trying now - where we check for:




  1. valid user auth

  2. expected value exists in userClaim variable request.auth.token.chatFlatList


However, the read listener for /messages is being blocked.




Error message:



FirebaseError: [code=permission-denied]: Missing or insufficient permissions






service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null
&& request.auth.token != null
&& request.auth.token.chatFlatList.val().contains($discussionId);
}
}




Details



We are using cloud functions for all data read/write, so for almost every case we can just block all client access.



The one exception is for the chat discussions, where we need to set a snapshot listener in the mobile client to know when there are new messages.



Sub-collection notes:



At a school, there are discussion sessions for school staff (teachers, admins, etc)



/schools/{schoolId}/chats/{discussionId}


Where each discussion-document contains:




  1. list of participant teacher ids

  2. subcollection for actual messages where each document is an indivual posted message:


/schools/{schoolId}/chats/{discussionId}/messages



User Claim code from Cloud Function



Looking at the cloud function logs, we have verified that the userClaim is being set.



return firebaseAdmin
.auth()
.setCustomUserClaims(
uid, {
chatFlatList: 'id1 id2 id3'
}
);


UPDATE #1



Tried the following variation where rules skip/omit the check on userClaim and auth.token.



However, still same permission error.



service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null;
}

}
}









share|improve this question
















Question:



For the different top-level firestore collections below, how to restrict access to all but one of the paths?




We are building a data schema in Firestore to support a chat app for teachers across multiple schools.



The top-level firestore collections include:




  • /siteAdminUsers

  • /schools

  • /schools/{schoolId}/teachers

  • /schools/{schoolId}/chats


Below is the security rules setup we are trying now - where we check for:




  1. valid user auth

  2. expected value exists in userClaim variable request.auth.token.chatFlatList


However, the read listener for /messages is being blocked.




Error message:



FirebaseError: [code=permission-denied]: Missing or insufficient permissions






service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null
&& request.auth.token != null
&& request.auth.token.chatFlatList.val().contains($discussionId);
}
}




Details



We are using cloud functions for all data read/write, so for almost every case we can just block all client access.



The one exception is for the chat discussions, where we need to set a snapshot listener in the mobile client to know when there are new messages.



Sub-collection notes:



At a school, there are discussion sessions for school staff (teachers, admins, etc)



/schools/{schoolId}/chats/{discussionId}


Where each discussion-document contains:




  1. list of participant teacher ids

  2. subcollection for actual messages where each document is an indivual posted message:


/schools/{schoolId}/chats/{discussionId}/messages



User Claim code from Cloud Function



Looking at the cloud function logs, we have verified that the userClaim is being set.



return firebaseAdmin
.auth()
.setCustomUserClaims(
uid, {
chatFlatList: 'id1 id2 id3'
}
);


UPDATE #1



Tried the following variation where rules skip/omit the check on userClaim and auth.token.



However, still same permission error.



service cloud.firestore {
match /databases/{database}/documents {

match /{document=**} {
allow read, write: if false;
}

match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null;
}

}
}






google-cloud-firestore google-cloud-functions firebase-security-rules






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 17 '18 at 19:00







Gene Bo

















asked Nov 13 '18 at 3:13









Gene BoGene Bo

5,35544192




5,35544192












  • Have you tried simply allowing all access to messages, just to see if the problem is specifically with the interpretation of chatFlatList?
    – Doug Stevenson
    Nov 13 '18 at 3:26










  • @Doug, post is updated with listing for trying rules setup as you descibe. I was wondering - is it maybe that the main "global rule" match /{document=**} , somehow overwrites the custom rule for messages? I was trying to find something in the docs that explains if at least 1 rule is matched for true, then that is enough .. not sure if I missed that detail, but didn't see it. Thanks
    – Gene Bo
    Nov 13 '18 at 3:39












  • You can reject the entire database like that, then allow specific parts. It's totally doable. You just can't allow some part of the database, then reject it later. Once allowed, always allowed for that user.
    – Doug Stevenson
    Nov 13 '18 at 4:21






  • 1




    Since firebase console asks for feedback - on this point I would just like to take the opportunity to say: Overall the different Firebase tiers have been straight fwd to ramp up on and work with. But - respectfully (big Firebase advocate here!) - security rules area has been the most cumbersome (not so intuitive) to navigate/manage. E.g. no real way to debug errors in the rules logic it seems. Simulator doesn't support debug logs to determine which rule is matching for true or false, nor allows userClaim cfgs. Either the rules cfg works or it doesn't :(. Any guidance, very apprect'd :). Thanks
    – Gene Bo
    Nov 15 '18 at 2:21












  • I understand, these are issues that people at Firebase are thinking about.
    – Doug Stevenson
    Nov 15 '18 at 3:11


















  • Have you tried simply allowing all access to messages, just to see if the problem is specifically with the interpretation of chatFlatList?
    – Doug Stevenson
    Nov 13 '18 at 3:26










  • @Doug, post is updated with listing for trying rules setup as you descibe. I was wondering - is it maybe that the main "global rule" match /{document=**} , somehow overwrites the custom rule for messages? I was trying to find something in the docs that explains if at least 1 rule is matched for true, then that is enough .. not sure if I missed that detail, but didn't see it. Thanks
    – Gene Bo
    Nov 13 '18 at 3:39












  • You can reject the entire database like that, then allow specific parts. It's totally doable. You just can't allow some part of the database, then reject it later. Once allowed, always allowed for that user.
    – Doug Stevenson
    Nov 13 '18 at 4:21






  • 1




    Since firebase console asks for feedback - on this point I would just like to take the opportunity to say: Overall the different Firebase tiers have been straight fwd to ramp up on and work with. But - respectfully (big Firebase advocate here!) - security rules area has been the most cumbersome (not so intuitive) to navigate/manage. E.g. no real way to debug errors in the rules logic it seems. Simulator doesn't support debug logs to determine which rule is matching for true or false, nor allows userClaim cfgs. Either the rules cfg works or it doesn't :(. Any guidance, very apprect'd :). Thanks
    – Gene Bo
    Nov 15 '18 at 2:21












  • I understand, these are issues that people at Firebase are thinking about.
    – Doug Stevenson
    Nov 15 '18 at 3:11
















Have you tried simply allowing all access to messages, just to see if the problem is specifically with the interpretation of chatFlatList?
– Doug Stevenson
Nov 13 '18 at 3:26




Have you tried simply allowing all access to messages, just to see if the problem is specifically with the interpretation of chatFlatList?
– Doug Stevenson
Nov 13 '18 at 3:26












@Doug, post is updated with listing for trying rules setup as you descibe. I was wondering - is it maybe that the main "global rule" match /{document=**} , somehow overwrites the custom rule for messages? I was trying to find something in the docs that explains if at least 1 rule is matched for true, then that is enough .. not sure if I missed that detail, but didn't see it. Thanks
– Gene Bo
Nov 13 '18 at 3:39






@Doug, post is updated with listing for trying rules setup as you descibe. I was wondering - is it maybe that the main "global rule" match /{document=**} , somehow overwrites the custom rule for messages? I was trying to find something in the docs that explains if at least 1 rule is matched for true, then that is enough .. not sure if I missed that detail, but didn't see it. Thanks
– Gene Bo
Nov 13 '18 at 3:39














You can reject the entire database like that, then allow specific parts. It's totally doable. You just can't allow some part of the database, then reject it later. Once allowed, always allowed for that user.
– Doug Stevenson
Nov 13 '18 at 4:21




You can reject the entire database like that, then allow specific parts. It's totally doable. You just can't allow some part of the database, then reject it later. Once allowed, always allowed for that user.
– Doug Stevenson
Nov 13 '18 at 4:21




1




1




Since firebase console asks for feedback - on this point I would just like to take the opportunity to say: Overall the different Firebase tiers have been straight fwd to ramp up on and work with. But - respectfully (big Firebase advocate here!) - security rules area has been the most cumbersome (not so intuitive) to navigate/manage. E.g. no real way to debug errors in the rules logic it seems. Simulator doesn't support debug logs to determine which rule is matching for true or false, nor allows userClaim cfgs. Either the rules cfg works or it doesn't :(. Any guidance, very apprect'd :). Thanks
– Gene Bo
Nov 15 '18 at 2:21






Since firebase console asks for feedback - on this point I would just like to take the opportunity to say: Overall the different Firebase tiers have been straight fwd to ramp up on and work with. But - respectfully (big Firebase advocate here!) - security rules area has been the most cumbersome (not so intuitive) to navigate/manage. E.g. no real way to debug errors in the rules logic it seems. Simulator doesn't support debug logs to determine which rule is matching for true or false, nor allows userClaim cfgs. Either the rules cfg works or it doesn't :(. Any guidance, very apprect'd :). Thanks
– Gene Bo
Nov 15 '18 at 2:21














I understand, these are issues that people at Firebase are thinking about.
– Doug Stevenson
Nov 15 '18 at 3:11




I understand, these are issues that people at Firebase are thinking about.
– Doug Stevenson
Nov 15 '18 at 3:11












2 Answers
2






active

oldest

votes


















1





+250









I think the issue here is that you are writing a rule on the collection called messages.




All match statements should point to documents, not collections.
https://firebase.google.com/docs/firestore/security/rules-structure




You should try adding /{document=**} after your path to messages, something like:



    match /schools/{schoolId}/chats/{discussionId}/messages/{document=**} {
allow write: if false;
allow read: if request.auth != null;
}





share|improve this answer





















  • That did the trick - Big Thanks!
    – Gene Bo
    Nov 29 '18 at 20:14



















0














Here's a solution (seems to be working), which includes the check on chatFlatList user claim variable (from original question) for a substring :



        match /schools/{schoolId}/chats/{discussionId}/messages {
allow write: if false;
allow read: if request.auth != null
&& request.auth.token.chatFlatList.matches(discussionId);
}


Figured this out thanks to:





  1. Firebase storage rules based on custom parameters




    • Here the post shows there is not any $ notation to access the path var. I recall seeing this in a security rules example code example - maybe it's specific to database tiers?



  2. https://firebase.google.com/docs/reference/security/storage/#string



  3. https://regex-golang.appspot.com/assets/html/index.html




    • Trying some example inputs here, to get an understanding for how to create the regex's.








share|improve this answer





















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53273250%2ffirebase-security-rules-to-restrict-access-on-all-paths-but-one%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1





    +250









    I think the issue here is that you are writing a rule on the collection called messages.




    All match statements should point to documents, not collections.
    https://firebase.google.com/docs/firestore/security/rules-structure




    You should try adding /{document=**} after your path to messages, something like:



        match /schools/{schoolId}/chats/{discussionId}/messages/{document=**} {
    allow write: if false;
    allow read: if request.auth != null;
    }





    share|improve this answer





















    • That did the trick - Big Thanks!
      – Gene Bo
      Nov 29 '18 at 20:14
















    1





    +250









    I think the issue here is that you are writing a rule on the collection called messages.




    All match statements should point to documents, not collections.
    https://firebase.google.com/docs/firestore/security/rules-structure




    You should try adding /{document=**} after your path to messages, something like:



        match /schools/{schoolId}/chats/{discussionId}/messages/{document=**} {
    allow write: if false;
    allow read: if request.auth != null;
    }





    share|improve this answer





















    • That did the trick - Big Thanks!
      – Gene Bo
      Nov 29 '18 at 20:14














    1





    +250







    1





    +250



    1




    +250




    I think the issue here is that you are writing a rule on the collection called messages.




    All match statements should point to documents, not collections.
    https://firebase.google.com/docs/firestore/security/rules-structure




    You should try adding /{document=**} after your path to messages, something like:



        match /schools/{schoolId}/chats/{discussionId}/messages/{document=**} {
    allow write: if false;
    allow read: if request.auth != null;
    }





    share|improve this answer












    I think the issue here is that you are writing a rule on the collection called messages.




    All match statements should point to documents, not collections.
    https://firebase.google.com/docs/firestore/security/rules-structure




    You should try adding /{document=**} after your path to messages, something like:



        match /schools/{schoolId}/chats/{discussionId}/messages/{document=**} {
    allow write: if false;
    allow read: if request.auth != null;
    }






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 28 '18 at 14:24









    Revolution88Revolution88

    640510




    640510












    • That did the trick - Big Thanks!
      – Gene Bo
      Nov 29 '18 at 20:14


















    • That did the trick - Big Thanks!
      – Gene Bo
      Nov 29 '18 at 20:14
















    That did the trick - Big Thanks!
    – Gene Bo
    Nov 29 '18 at 20:14




    That did the trick - Big Thanks!
    – Gene Bo
    Nov 29 '18 at 20:14













    0














    Here's a solution (seems to be working), which includes the check on chatFlatList user claim variable (from original question) for a substring :



            match /schools/{schoolId}/chats/{discussionId}/messages {
    allow write: if false;
    allow read: if request.auth != null
    && request.auth.token.chatFlatList.matches(discussionId);
    }


    Figured this out thanks to:





    1. Firebase storage rules based on custom parameters




      • Here the post shows there is not any $ notation to access the path var. I recall seeing this in a security rules example code example - maybe it's specific to database tiers?



    2. https://firebase.google.com/docs/reference/security/storage/#string



    3. https://regex-golang.appspot.com/assets/html/index.html




      • Trying some example inputs here, to get an understanding for how to create the regex's.








    share|improve this answer


























      0














      Here's a solution (seems to be working), which includes the check on chatFlatList user claim variable (from original question) for a substring :



              match /schools/{schoolId}/chats/{discussionId}/messages {
      allow write: if false;
      allow read: if request.auth != null
      && request.auth.token.chatFlatList.matches(discussionId);
      }


      Figured this out thanks to:





      1. Firebase storage rules based on custom parameters




        • Here the post shows there is not any $ notation to access the path var. I recall seeing this in a security rules example code example - maybe it's specific to database tiers?



      2. https://firebase.google.com/docs/reference/security/storage/#string



      3. https://regex-golang.appspot.com/assets/html/index.html




        • Trying some example inputs here, to get an understanding for how to create the regex's.








      share|improve this answer
























        0












        0








        0






        Here's a solution (seems to be working), which includes the check on chatFlatList user claim variable (from original question) for a substring :



                match /schools/{schoolId}/chats/{discussionId}/messages {
        allow write: if false;
        allow read: if request.auth != null
        && request.auth.token.chatFlatList.matches(discussionId);
        }


        Figured this out thanks to:





        1. Firebase storage rules based on custom parameters




          • Here the post shows there is not any $ notation to access the path var. I recall seeing this in a security rules example code example - maybe it's specific to database tiers?



        2. https://firebase.google.com/docs/reference/security/storage/#string



        3. https://regex-golang.appspot.com/assets/html/index.html




          • Trying some example inputs here, to get an understanding for how to create the regex's.








        share|improve this answer












        Here's a solution (seems to be working), which includes the check on chatFlatList user claim variable (from original question) for a substring :



                match /schools/{schoolId}/chats/{discussionId}/messages {
        allow write: if false;
        allow read: if request.auth != null
        && request.auth.token.chatFlatList.matches(discussionId);
        }


        Figured this out thanks to:





        1. Firebase storage rules based on custom parameters




          • Here the post shows there is not any $ notation to access the path var. I recall seeing this in a security rules example code example - maybe it's specific to database tiers?



        2. https://firebase.google.com/docs/reference/security/storage/#string



        3. https://regex-golang.appspot.com/assets/html/index.html




          • Trying some example inputs here, to get an understanding for how to create the regex's.









        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 17 '18 at 19:06









        Gene BoGene Bo

        5,35544192




        5,35544192






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53273250%2ffirebase-security-rules-to-restrict-access-on-all-paths-but-one%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            這個網誌中的熱門文章

            Academy of Television Arts & Sciences

            L'Équipe

            1995 France bombings