rulesand there are two kinds of permissions,
.write. There's also an
authobject available in the rule conditions which we can test to make sure that it's not null. If it's not null, then the request must be coming from an authenticated user!
usersnode on our imaginary JSON tree.
rulesand we called that node
users? Yeah, we're nesting our rules to match our data. So
usersnode in the JSON.
.validatemust all be set to
falseor a string "condition" that the security rules engine will need to evaluate.
.writeare simple enough. They grant read or write access.
.validatewill prevent a write if it's condition statement evaluates to false.
.indexOnfield is necessary to speed up RTDB queries, and it's either the string
".value"or an array of strings representing the attributes to index.
.indexOncould be used like this:
$userIdindicates that it's a wildcard. You an name wildcards whatever you like. You could have named it
$broccoli... but then you'd have to refer to the wildcard as
broccoliin your condition statements :)
userThree. Also let's assume that we want
userThreeto be able to write to everyone's records as well as read and write to her own.
$userIdwildcard to set rules for all users. Then, by specifying
rules.users.userThree, we overrode the wildcard for
superSecretUserAttributesjust failed, because we granted
.readaccess higher up the chain. In this example, all users can still read
superSecretUserAttributesand the nested
.readrule gets ignored.
$objectTypenested directly underneath it? That's so we can save lots of different types of objects, all of which will inherit their rules from their parent nodes.
adminclaim to read and write everything using
auth.token.admin === true. Custom claims are awesome, because they're available across all three types of security rules—Firestore, RTDB and Storage—as well as your browser's
.validatesecurity rule will let you do validation right at your data layer.
.writerules can give you, it's time for some