Firebase sharing data with other users

Question

I want to create item lists using Firebase that can be created by a user and then he can specify other users to share the list with (so they can also modify its contents). I plan to do this by using the following structure:

So the user section specifies the lists that a user has. Then the node 'lists', all lists created have a unique id and for each list its members are specified:

In this example, Rick is the admin of the list and Tom just a member. Now I want the rules to, for example, only allow reading and writing under the 'items' node, if the user id is present under the 'members' node.

Now I have two questions: 1. Is this approach the correct on or should my entire data structure be different for this purpose? 2. If the structure is fine, how should I write the rules such that the above described behavior is obtained and how do I generate a unique id for each list?

Answer 1

At first glance this seems like a reasonable starting point. I'd just replace the "values that are the same as the key" with a simple true, to save a few bytes of storage/bandwidth. Aside from that it's hard to give more "hard" advice without knowing all use-cases.

You might also want to consider a recent change: security rules can now validate queries, which means that you could potentially do without the /users/$uid/lists index. I recommend that you try this and see if it works for your use-case.

To allow read access to a list only to members of that list, these rules could be a starting point:

{
  "rules": {
    "lists": {
      "$listid": {
        "items": {
          ".read": "
            data.parent().child('members').child('admin').val() === auth.uid ||
            data.parent().child('members').child(auth.uid).exists()
          "
        }
      }
    }
  }
}

The first line of that .read rule grants read access to the admin. The second line then grants read access to all other users.

Finally: as always I recommend reading NoSQL data modeling and watching Firebase for SQL developers.