HTML syntax for granular permissions

[LeaVerou]

When Mavo started, we were only using flat files to store all Mavo app data remotely, and backends that were basically file stores. Therefore, there was no way of only being able to read/edit part of the data: either you were able to read/edit all of it, or none of it. The set of possible permissions were very small, and Mavo conveniently read it from the backend and applied it to the UI.

This works well for apps where the data is only managed by one person or a small team of people that trust each other, such as PIM apps and CMS-style applications. However, it makes several types of apps impossible, such as:

• Comments and ratings on collection items (read: public, write: own)
• Surveys (read: admins+own, write: own)
• Chats and discussions of any sort (read: *, write: own)

Thankfully, this restrictive assumption is challenged by new backends like Firebase. This means, there needs to be a way for Mavo authors to describe these granular permissions in their HTML. 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. Sure, the Backend could read them remotely, parse them and apply them, but that's an extra step that not all backend authors do.

We've already seen that backend authors tend to expect HTML authors to duplicate the permissions in their HTML, and have to invent their own syntax, which sometimes even goes against best practices:

• @valterkraemer’s Firebase plugin uses a mv-unauthenticated-permissions="read edit save" attribute
• @lizziew’s Firebase plugin expects keywords like public-read, public-write, user-write in the mv-app attribute (!).

Since this is a common need, we need to devise a syntax for it, and have Mavo process it, apply it in the UI, and expose it to the backends. This will also mean that backend authors are more likely to support granular permissions in that case, as it's much less work for them.

I will start trying to come up with a good syntax with some brainstorming:

Types of permissions

Currently, Mavo supports the following types of permissions:

• Read
• Add
• Delete
• Edit (also sets add + delete to true)
• Save
• Login (available only to unauthenticated users on backends that support authentication)
• Logout (available only to authenticated users on backends that support authentication)

Currently, Mavo reads these permissions from the backend, and exposes them on an mv-permissions attribute on the Mavo root. The mv-permissions attribute is read-only, and setting it doesn’t do anything.

User targets

The following scopes seem most useful, but perhaps I'm missing some:

• Nobody
• admins or specific named user group, for backends that support that
• logged in users
• creator of item
• everyone

The last three are probably the most useful, and should be included in even the tiniest MVP of this.
Possibly also combinations of the above, e.g. "logged in users except banned user group".

Potential syntaxes

1. We use one attribute whose value is a key-value list, like read: everyone, add: logged-in, edit: own, delete: own. If a permission is provided without a value, the implied value is "everyone".
   Name brainstorming for this attribute: mv-permissions, mv-can, mv-enable
2. We use separate attributes, e.g. mv-can-read="everyone" mv-can-add="logged-in" mv-can-edit="own" mv-can-delete="own". If an attribute is used without a value, the implied value is "everyone".

In both proposals, undeclared permissions would be inherited.

We need feedback about:

• Are the user targets above sufficient? Can you think of something else that you need?
• Do you prefer one or multiple attributes? Or perhaps you can think of a different syntax entirely?
• Any ideas about the names of the attributes and/or their values?

[valterkraemer]

Would there be defaults if no permissions are set?

Not syntax related, but if there are no defaults, the author has to set all permissions which would make syntax 1 a bit clearer. While if there are defaults, the user probably have to set less that would make syntax 2 clearer.

On a element with mv-multiple, would mv-can-edit="own" be equal to mv-can-edit="own" mv-can-add="logged-in" mv-can-delete="own"?

My vote go to multiple attributes, and mv-can-*.

To be consistent I think own should be owner and either of the combinations:

• everyone, no-one
• everybody, nobody
• all, none

[joyously]

Would the *nix system type of permissions fit this?
It's user, group, other having read, write, execute permissions each.
And would there be a fallback of local storage for those without permission to write? But that implies a different storage backend for each piece of data, which I'm not sure you were talking about.

[LeaVerou]

@joyously many of the common use cases I mentioned wouldn't be possible to define that way.

[LeaVerou]

@valterkraemer

To be consistent I think own should be owner

I think depending on the Mavo app, it may be confusing to think of the "owner" of each item as a concept, whereas "my own items" is pretty straightforward regardless of the schema.

[LeaVerou]

A different idea would be to have very very simple attributes (basically yes/no for each permission) and offload the complexity to expressions. Then, we would expose any information needed to implement common permission patterns via special properties in expressions, and update it accordingly upon login/logout.

The main drawback is that this would make it much harder to read this server-side and enforce the permissions, without requiring the author to specify them again. It would also make it much harder to automatically transform the permissions to whatever format the backend expects.

Attributes could be something like mv-can-view, mv-can-edit, mv-can-add, mv-can-delete

Special properties that need to be exposed in expressions would be:

• Info about current user: $username, $avatar, $name (these could also be used by the Mavo toolbar instead of the current custom code)
• Info about the user who first created an object ($creator?)

Then logged in becomes just $username, own items becomes just $username = $creator and so on.

[LeaVerou]

Issues that are blocking this:

• New special properties for currently logged in user #351 (to enable specifying meaningful conditions)
• Collections should be represented in the DOM #72 (to enable different permissions on collections and their items)

Anything else?