Firebase security rule allow access only to nested item - firebase

Question

I'm following the suggested data model from this tutorial for counting upvotes in a firebase database:
-| upvotes
-| itemId
-| userId: number
This works fine but the problem I'm encountering is how to allow users to only be able to update their own upvote. If I use something like this:
match /votes/{id} {
allow read: if true;
allow write: if request.auth != null;
match /{uid} {
allow read: if true;
allow write: if uid == request.auth.uid;
}
}
Then any authenticated user can edit the entire vote entry. But if I try to restrict to just the /uid match:
match /votes/{id} {
allow read: if true;
match /{uid} {
allow read: if true;
allow write: if uid == request.auth.uid;
}
}
Then I get insufficient permissions when I try to alter the record. Any ideas how to work around this?

Answer 1

In a situation like this where you have mixed private and public access, you might find it easier to break apart the write rule into its components: create, update and delete.
Using the features of the Map, MapDiff and List interfaces in your security rules allows you to implement the following restrictions:
match /votes/{id} {
// anyone can read
allow read: if true;
// Anyone can create a new vote pool, as long as they mark
// themselves the owner first, they can optionally cast their
// own vote at the same time.
allow create: if request.auth.uid == request.resource.data.ownerId
&& request.resource.data.keys().hasOnly(["ownerId", request.auth.uid]);
// Anyone can update the vote pool, but they can only change data
// under their own userId (such as adding/updating/removing their
// vote). Even owners can only update their own vote once created.
allow update: if request.resource.data.diff(resource.data).affectedKeys().hasOnly([request.auth.uid]);;
// only the owner can delete a vote pool
allow delete: if request.auth.uid == resource.data.ownerId;
}
Important: These rules do not currently restrict what is written under the user's ID. With the current rules, a malicious user could write large amounts of data under that key. It is up to you to decide what can and can't be written there.
Note: You may want to adjust the above rules so that you can give the vote pool a title. I'll leave it as an exercise to the reader on how to make sure it is provided at creation with a proper value. You can optionally make the title editable, but that should be discouraged as the results can be viewed differently depending on the title change. You can also implement the ability for the owner to lock the vote pool and prevent further changes.