I read through the collection group query documentation and was wondering if the recursive wildcard (rules_version = '2') {path=**} was mandatory in order for collection group queries to work.
I will give you an example (following the example from the documentation):
The database uses a forums collections with different forums.
Each forum can have multiple posts.
This results in the following structure: forums/{forum}/posts/{post}.
Both of the following snippets will successfully match all posts:
match /forums/{forum}/posts/{post} {
allow list;
}
match /{path=**}/posts/{post} {
allow list;
}
If I understand the documentation correctly, the first match would not be enough in order for a collection group query on posts to work.
I understand that the second match will also match any other subcollection with the name posts.
Is the first match enough?
If not, does the recursive wildcard {path=**} always have to be top-level, i.e. directly in match /databases/{database}/documents? The documentation makes it look like it was the case.
The documentation suggests that your first rule is not sufficient to allow a collection group query on posts.
In your security rules, you must allow this [collection group] query by writing a read or list rule for the posts collection group.
match /{path=**}/posts/{post} {
allow read: if request.auth.uid != null;
}
If you're asking if security rules can be used to constrain a collection group query to a subset of subcollections called "posts", that is not possible. All collections called "posts" will be considered in the query. This is why the wildcard must also be at the beginning of the match path, because anything else would still be an attempt at constraining the set of collections.
This is all just a variation of the primary rule that security rules are not filters. They can neither filter documents for regular queries, nor collections for collection group queries.
The documentation does go further to help you understand how to model your data so that you can apply a filter on the client, and match that to fields that exist in the documents being search. The client may always filter results with a where clause, but it must also match the constraints of the security rules.
