Persist Context and Roles

[dylancwood]

Hi @carlos8f! Thank you for the very excellent module. I've benchmarked this against node-acl, and your module is about 25% faster for simple permissions assertions 👍 Additionally, our team likes the use of natural language, as it keeps our syntax very clean.

One thing that we are trying to deal with is persisting contexts and roles to our datastore so that they can be loaded at runtime. Before submitting a PR to add context storage to the datastores, I wanted to see if there was some reason that the contexts and their roles are not persisted already. We would like any existing contexts and roles to be retrieved from the datastore on datastore initialization.

Thank you in advance for clarifying this for us.

[carlos8f]

Basically I left that part out because contexts/roles already persist in a way: in your code. introducing a second persistence requires keeping them in sync, i.e. if your code definition changes, the stored schema needs to update (and what happens to existing assignments then?). I thought that would be better done by custom/app-level code, which might also take care of other migrations in your app. Migrations is beyond the scope of this module, and by association, schema persistence. If you'd like, you could create a relations-schema module to provide the feature on top of relations?

[dylancwood]

Thank you for the reply. After thinking it over, I see your point quite clearly. In our case, I believe that it would make more sense to store some basic descriptors from which the context can be generated, as opposed to storing the entire context and its roles. I will try to do it in a generic way that can be leveraged by other users of node-relations.

While I have your attention, I am hoping to get your assistance with a conceptual problem I am having with ACL/relations: To pick up on your github-based example, how would you go about adding access control to pull requests? Access to a PR is not based on the PR identifier, but rather, it is based on the person's role on the repository. Here are a couple of options that I came up with, but I would appreciate your thoughts.

Option 1: treat pull requests as actions

var relations = require('relations');

relations.define('repos', {
  owner: ['pull', 'push', 'administrate', 'open_pr', 'close_pr', 'merge_pr'],
  collaborator: ['pull', 'push', 'open_pr', 'close_pr', 'merge_pr'],
  watcher: ['pull', 'open_pr']
});

This feels uncomfortable because I am mixing resources and actions.

Option 2: create an additional context for PRs

var relations = require('relations');

relations.define('repos', {
...
});

relations.define('pullRequests', {
 owner: ['open', 'close', 'merge'],
  collaborator: ['open', 'close', 'merge'],
  watcher: ['open']
});

In this case, whenever a new PR is created, we will need to assign a role for that PR to each user that already has a role on the repo.