Reputation: 848
I was wondering what the convention was with regard to undefined properties with firestore security rules.
For example in the following rule that checks a custom claim:
allow read: if request.auth.token.claims.admin;
There are many points for an undefined property error, by far the most likely being if a user is not authenticated then request.auth
will be undefined, so request.auth.token.claims.admin
will be trying to access a property of an undefined value.
I have noticed that in the documentation request.auth.uid
is a common check and they don't check if request.auth
is defined first. However, in my research I noticed that some people do perform the check for similar queries, for example in this stack overflow answer.
Below is an annotated screenshot of what the simulator returns. My understanding is that this check for undefined properties is not necessary for security. My question is rather what the standard is and if not checking for undefined properties is the standard then why does the simulator throw an error?
On a side note which of the following (implicit or explicit boolean conditions) is preferred and why:
allow read: if request.auth.token.claims.admin;
allow read: if request.auth.token.claims.admin == true;
Upvotes: 2
Views: 1542
Reputation: 317750
Firstly: All errors in rules evaluation result in an error. An error, without any conditioning, results in a rejection of access. So, if you try to access a property of a null or undefined object, that's an error (since that property doesn't exist), and results in an immediate rejection of access.
If you want to explicitly check for null in your rules, that's fine. That likely helps the readability of those rules. But you're not obliged to do so because of the immediate rejection of the access. It's entirely up to you.
Upvotes: 4