In Firestore Security Rules, what's the definition of 'allow'?

[M Mathems]

Hi

I'm at a point of confusion where i'm interested in a confirmation of the basics and what seems simple and obvious regarding Firestore Security Rules.

I'd like to know what 'allow' means when stated with conditions within security rules.

For example, does 'allow read: if ...' mean that documents within the relevant collection can be read if they meet the set condition, or, does 'allow read: if ...' mean that if the condition is met once that the user can access every document within the relevant collection?

I was thinking that a conditioned allow-read statement would permit a user to read from the relevant collection, but only those documents that match the condition.  Am I mistaken and confused please?

With thanks.

[Mark Duckworth]

> I'd like to know what 'allow' means when stated with conditions within security rules.

`allow read:...`, `allow write:...`, `allow get:...`, `allow <op>: ...` are all just part of a statement that defines when the specified <op> is allowed on a matching document. The operation on the document is allowed when the condition on the right side of the statement `allow <op>: if <condition>` evaluates to true for any rule matching the document.

> I was thinking that a conditioned allow-read statement would permit a user to read from the relevant collection, but only those documents that match the condition.

I think what you are asking is if security rules will filter your Firestore query results? The answer is no, "you cannot write a query for all the documents in a collection and expect Cloud Firestore to return only the documents that the current client has permission to access." It's important to understand that the security rule will deny an entire collection read (or query read) if the security rule *could possibly* evaluate to false for a document in the query result. The documentation and examples demonstrate this concept: https://firebase.google.com/docs/firestore/security/rules-conditions#rules_are_not_filters

Mark

[M Mathems]

Hi Mark

Thank you for your response.

If I accept your explanation of the meaning of 'allow' then it would allow me to evaluate certain results, for whether they are right or an error on Firestore's part.  So maybe I have already noticed the best possible result, and maybe I have had a higher expectation.

In relation to what you have explained about Firestore not filtering query results, I have read this before in the Firebase documents, but recently I have come to wonder whether or not I have interpreted those words correctly.  Firestore's no-filtering policy might also mean I must find a way for every document to be returnable (whether relevant or not), but limit the receipt of returned documents to users with the user-interface code.

Many thanks

[Mark Duckworth]

> for whether they are right or an error on Firestore's part

> maybe I have had a higher expectation

What is the behavior you expect? Can you give an example of how the current behavior is an error?

> Firestore's no-filtering policy might also mean I must find a way for every document to be returnable (whether relevant or not)

Security rules will not apply a filter, but you can add a filter in your query in addition to the security rule. That might help you get your desired behavior.

So a rule like:
`allow read: if resource.data['owner_id'] == request.auth.uid`

Could be queried with
`query(collection("/owned-documents"), where("owner_id", "==", myUid))`

Thanks,

Mark

[M Mathems]

Hi Mark

What happened was, I drafted a rule to set up exclusive/selective reading of a collection, and I expected to notice a document read and another ignored - I placed alternative field values in two documents for a fair test.  The result was that Firestore denied access saying the caller has no permission, and, not realising that this was due to Firestore's policy (the one you have made clear), I was unaware that I had already received the best result from Firestore.

So, moving forwards, I recognise that any security rule must be for the user to have full-access to the collection's data, and that any filtering of that collection's data must take place within the code that creates the user-interface.

Many thanks for your time and for your explanations  🙂

[M Mathems]

Hi Mark

Do you know about the get(/databases/) calls for Firestore security rules by any chance?

What's happened is, I've changed some things based on what you have explained, but I am still getting the same result, which leads me back to wanting the correct result.

The new rule would offer full access to the user if they have a uid and if a field confirms 'X' -- admin for example.  But the same permission denial is the result.

I expect a different result now because the rule does not create exclusive/selective reading of the collection.

Please share your thoughts.

With thanks.

On Wednesday, 3 May 2023 at 19:45:48 UTC+1 markdu...@google.com wrote: