Metadata fields in subcollection?

[nathan815]

Unfortunately Firestore doesn't allow one to specify rules at the field level, meaning the metadata fields are publicly accessible. created_at and updated_at aren't too big of a deal, but updated_by and created_by are more concerning to have publicly accessible IMO.

It is recommended to store private info in a subcollection because Firestore rules allow restricting access to subcollections. So I am wondering if there is currently a way to have react-admin-firebase store the metadata within a subcollection?

Example: In /collection/documentID/private/metadata, 'metadata' would be the document name in which metadata is stored within the 'private' subcollection.

P.S. this is an excellent package, well done @benwinding 👍

[benwinding]

Hi @nathan815,

but updated_by and created_by are more concerning to have publicly accessible IMO.

Well, this depends on the global rules you have. You could make the rules require the client is authenticated, which would mean the database is not public, like the following example (source).

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

It is recommended to store private info in a subcollection because Firestore rules allow restricting access to subcollections.

That's a good point, I wasn't aware that Firestore recommended that, but it makes sense.

So I am wondering if there is currently a way to have react-admin-firebase store the metadata within a subcollection?

This is definitely possible, and a great idea. It would double the amount of reads required though, but in a lot of cases that's probably acceptable. The following changes could be made to get this done:

• When writing to a document, also write to private/metadata subcollection
• When deleting a document, also delete private/metadata subcollection
• When reading a document, also read the private/metadata subcollection

Seems doable and would be a good option to have in the package, will think about this a bit more and keep you updated.

Cheers, Ben

[nathan815]

Well, this depends on the global rules you have. You could make the rules require the client is authenticated, which would mean the database is not public

That's true, though for my use case I need the collection to be publicly readable. And even if the client were authenticated it may not be good for them to know who created/modified the data last.

I did realize this isn't as big of a deal when the associateUsersById option is enabled, though. For me it was more of an issue of exposing email address of who updated the document.

Seems doable and would be a good option to have in the package, will think about this a bit more and keep you updated.

Great, would be happy to help out with this.