Home > database >  Firebase - organizing shareable data?
Firebase - organizing shareable data?

Time:01-06

I am trying to implement sharing model like in Google Docs. That is:

  1. "Documents" are private by default.
  2. Some documents are accessible to everybody.
  3. Some documents are shared with users.

Right now my database stores document metadata in the database in per-user collections (${userid}/docs/${docid}) and Firebase Storage is used to store assets under similar paths. I set up trivial security rules to manage that.

Now I am trying to figure out sharing:

  1. Should I move all documents into a global docs collection and have security rules check ACLs that are in the docs metadata?
  2. Should I try to replicate shared documents in each user collection? Seems brittle but cloud functions should help with synchronizing data.
  3. Keep documents under owning users and have security rules check permissions.

Is it even possible to have Firebase Storage security rules consult Firebase to fetch metadata?

Obviously, I am trying not to go overboard with database access, money is tight.

CodePudding user response:

Should I move all documents into a global docs collection and have security rules check ACLs that are in the docs metadata?

The simplest solution would be to create a global collection, where each document should have an array-type field, that should contain the UIDs of the users that are allowed to read. The absence of the field should mean that the document is private. You should always check in your application code if a particular UID exists in the array, but the most important thing is to check that in your security rules. To be able to do that, you need to have to sign the user into Firebase Authentication. As soon as the user is authenticated the request.auth variable (including request.auth.uid) becomes available, meaning that their token is automatically passed with any calls to Firestore.

Should I try to replicate shared documents in each user collection? Seems brittle but cloud functions should help with synchronizing data.

This practice is called denormalization, and it's quite common practice when it comes to NoSQL databases like Firestore. But I cannot see any reasons why you would do that. It's not necessary in this case.

Keep documents under owning users and have security rules check permissions.

It doesn't really matter where the documents exist, you always use security rules against malicious users.

  • Related