Discussion: Better alternative to user abilities based on roles

Issue 内の ability の例から始め、特に projectMembership、userRole、route before/afterModel checks を確認してください。記載されている current-user sideloading と API abilities の選択肢を検討してください。完了の条件は、非同期の ability チェックと過剰な project membership requests に対する合意済みの解決策があることですが、ファイルやテストは指定されていません。

Problem

Right now, most of our authorization stuff is based in a user's membership level in a project. They can be unrelated, they can have a pending membership (meaning they requested membership, but they are yet to be approved), or they can be any of [contributor, admin owner].

Based on the level of their role, they are allowed or not allowed to perform certain project-related actions.

First Problem: Amount of requests

In order to determine a role level of a user in a project, we usually need to perform the following:

1. fetch project.projectUsers
2. for each projectUser, actually load the record from the backend, because just having the id is not enough.

Right now, this is not a big deal performance-wise. However, we expect projects to grow, and this is, worst-case, n+1 requests for a project with n members. Luckily, we use colasced id requests to significantly reduce this, but it's still something that's potentially problematic.

Second Problem: Ember-Can does not play well with async

The ability above is a computed, the content of which is partially dependant on async network requests.

Basically, in most cases we have something like this:

projectMembership: computed('project.projectUsers', 'currentUser.user.id', function() {
  let currentUserId = get(this, 'currentUser.user.id');

  if (isEmpty(currentUserId)) {
    return false;
  } else {
    return get(this, 'project.projectUsers').find((item) => {
      return get(item, 'user.id') === currentUserId;
    });
  }
}),

userRole: alias('projectMembership.role'),
userIsContributor: equal('userRole', 'contributor'),
userIsAdmin: equal('userRole', 'admin'),
userIsOwner: equal('userRole', 'owner'),

canEdit: or('{userIsAuthor,userIsAdmin,userIsOwner}'),
canAssign: or('canEdit', 'userIsContributor'),
canReposition: alias('canAssign')

With template usage, where we do or do not render parts of the UI based on abilities, this works amazingly well, mostly thanks to DS.PromiseObject and DS.PromiseArray classes.

As results are being fetched, eventually, we will get a currentUserId and we will get a projectMembership.role. Until that happens, the ability is evaluated as false. For templates, this is almost exactly what we need. Eventually, when we determine a user is able to do something, that part of the UI will render.

For the case of routes and redirecting in case of lack of abilities, this is problematic. In those cases, we basically get the current value of the ability, which is usually false at the moment of a route's before/afterModel hook. Due to that, we are forced to use a dirty solution of explicitly fetching records before checking the ability:

return get(project, 'projectUsers').then(() => {
  if (this.cannot('manage project', project)) {
    return this.transitionTo('project');
  }
});

Its a very clear code smell and it will end up being highly problematic as the number of users grows.

We need a solution, primarily for the second, but also for the first problem

Potential solutions

We sideload the projectUser relationship as part of the user request

This works, but also means a lot of data we don't need being loaded. Most user will not need information for other user records.

We sideload the projectUser relationship, but only for the current user.

Our API could sideload it in this specific case, if the GET /users/:id matches the currently authenticated user.

Really, this would tackle most cases. We'd have to rethink our currentUser/abilities structure, but it could work quite nicely, I think.

We could go further and have the authentication request return a user record with all the sideloaded information, which we can then push into the ember store manually.

The more I think about it, the more I like this solution.

We send some sort of computed ability table structure for each user

Probably highly complex and something I'm not looking forward to tackling and would vote against, but wanted to get the option listed here anyway.

Have some sort of ability endpoint on the API, which can tell each user if they can/cannot do something.

Again, a solution I do not personally like, but listing it for the sake of discussion.

Other options

Listed above are the options I could think of, but there may be other.

Side effects

Depending on how we deal with this, we could eliminate the need to fix #1151