Recursive wildcards in Firestore security rules not working as expected

Question

I have a data structure like this (Collections and Documents rather than JSON of course but you get the idea):

{
   users: {
      user1:{
         name: Alice,
         groups: {
            groupA:{subbed:true},
            groupB:{subbed:true}
         }
      },
      user2:{
         name: Bob,
         groups: {
            groupC:{subbed:true},
            groupD:{subbed:true}
         }
      }
   }
}

Basically this is registered users IDs and the group IDs that each user is subscribed to. I wanted to write a security rule allowing access to a users profile and sub-collections only if they are the current auth user and, based on my reading of the docs, I thought that a wildcard would achieve this...

match /users/{user=**}{
   allow read,write: if user == request.auth.uid;
}

With this in place I can read the user document fine but I get a permissions error when I try and read the groups sub-collection. I can only make it work by matching the sub-collection explicitly...

match /appUsers/{user}{
   allow read,write: if user == request.auth.uid;

   match /groups/{group}{
      allow read,write: if user == request.auth.uid;
   }
}

...so my question is, what is the difference between the two examples and what am I misunderstanding about the recursive wildcards? I thought that the {user=**} part of the first example should grant access to the user document and all its sub-collections, sub-sub-collections etc etc ad infinitum (for the authorised user) and should remove the need to write rules specifically for data stored lower down as I have had to do in the second example.

I've only been messing around with Firestore for a short time so this could be a real dumb question :)

Thanks all

Answer 1

The firebase docs are a bit confusing when it comes to using the recursive while card. What I found in testing was that I needed to set two rules to give a user permission to write to the users document and all sub collections (and their sub documents) which is the most logical setup for managing user data.

You must set two rules.

1. Give user permission to the /users/{userId} document

2. Give user permission to all sub collections and their sub documents that begin at the /users/{userId} path.

   service cloud.firestore { match /databases/{database}/documents { match /users/{userId} { allow read, write: if request.auth.uid == userId; } match /users/{userId}/{document=**} { allow read, write: if request.auth.uid == userId; } } }

Rules

Sorry about including the images. I couldn't get SO to format them correctly.

Answer 2

I think the problem is that, while you are indeed using the subcollections wildcard =**, you are then allowing permissions only if user == request.auth.uid, so this is what happens (pseudocode):

(when accessing users/aHt3vGtyggD5fgGHJ)

user = 'aHt3vGtyggD5fgGHJ'
user == request.auth.uid? Yes
allow access

(when accessing users/aHt3vGtyggD5fgGHJ/groups/h1s5GDS53)

user = 'aHt3vGtyggD5fgGHJ/groups/h1s5GDS53'
user == request.auth.uid? No
deny access

You have two options: either you do as you've done and explicitly match the subcollection, or use this:

function checkAuthorization(usr) {
   return usr.split('/')[0] == request.auth.uid;
}
match /users/{user=**}{
   allow read,write: if checkAuthorization(user);
}

(the function must be inside your match /databases/{database}/documents, like your rule)

Let me know if this works :)

Answer 3

Security rules now has version 2.

match/cities/{city}/{document=**} matches documents in any subcollections as well as documents in the cities collection.

You must opt-in to version 2 by adding rules_version = '2'; at the top of your security rules.

Recursive wildcards (version 2).

This is what works for me:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}