search

DmitrySharabin / mavo-firebase-firestore

Firebase backend plugin for Mavo. Store and sync app data in milliseconds. Store and serve files at Google scale. Authenticate users simply and securely. All the Google Firebase powers are at your fingertips.
https://plugins.mavo.io/plugin/firebase-firestore
MIT License
6 stars 0 forks source link

Granular permissions #1

Open DmitrySharabin opened 4 years ago

DmitrySharabin commented 4 years ago

To start working on this feature, I need to clarify a couple of things.

Firstly, every property and its value (values for collections) needs to be stored with some extra metadata:

  1. A set of permissions—for a property or a collection itself—either provided by Mavo or read form the corresponding attributes or inherited from the parent element(?)
  2. Info about the creator of the object—for the value of every property—it might be the value of the user property, which is provided by a backend or any special properties provided by Mavo, e.g., $creator, $user, etc.
  3. Anything else?

Does it mean that for now, we need to define a new storage format for the Firebase plugin? I suppose yes. Because for now, the plugin stores the JSON file provided by Mavo, and it hasn't got any metadata. Firebase adds some extra data, but they are about the file itself (an id of a user created/modified the file, date and time of its creation/modification, maybe something else, I'm not sure), not its content. A new storage format would become some kind of polyfill till the Mavo core gets the granular permissions feature.

Secondly, in this issue, Lea describes new attributes for granular permissions (I know it can be a WIP, but I need some starting point): mv-can-view, mv-can-edit, mv-can-add, mv-can-delete. And here we can find the set of values for them: public, own, no.

Questions:

  1. Don't we also need the mv-can-save attribute, do we?
  2. By specifying the mv-can-edit attribute, we automatically propagate its value to the mv-can-add and mv-can-delete attributes if their values are not specified explicitly, don't we?
  3. Are there any other permissions propagation rules we need to be aware of?

@leaverou Lea, will you please have a look at my thoughts? Did I miss something?

DmitrySharabin commented 4 years ago

Other useful quotes from the corresponding issue in the Mavo repo:

Ideally, the remote backend would read these permissions, verify them with the admin when they are logged, and set them remotely too. But even backends that require setting permissions separately need to reflect them into the UI somehow.

Unfortunately, that leaves the question about data structure open. Firebase security rules are not filters: we can only use some built-in variables and get access to some piece of data in the queried documents before letting users have access to its full content.

If a permission is provided without a value, the implied value is "everyone".

i.e. public for now.

DmitrySharabin commented 4 years ago

Secure data access for users and groups—a guide on the Firebase site.