Status of this module about feathers-permissions

[daffl]

This module is now published with functionality as documented in the Readme.

[kristianmandrup]

"A version of feathers-permissions with noteable enhancements has been proved in the wild"

Where in the wild?

[subodhpareek18]

Why don't we guys start building your own utils till then. I'm using a role & a permission db with every user getting a role and role having a bunch of permissions.

I kept the first cut very simple with the pattern service:method, will add more dimensions later like service:method:scope where scope defines the ownership hierarchy.

Here is a very small hook that implements the first cut. Not the exact one I'm using as that has some more logic specific to my use case.

import R from 'ramda';

export const authorize = () =>
  iff(
    isProvider('external'),
    async ctx => {
      const userPermissions = R.path(
        ['params', 'user', 'role', 'permissions'],
        ctx
      );
      const types = R.pluck('type', userPermissions);
      const hasPermissions = R.any(
        p => p === `${ctx.path}:${ctx.method}`,
        types
      );
      if (!hasPermissions) {
        throw new errors.Forbidden('Not allowed to execute this action.');
      }
      return ctx;
    }
  );

[daffl]

@TimNZ I'm always happy about constructive criticism but your comment does neither further this discussion nor pay my rent so by all means, you are free (as in free software) to do so.

[poupryc]

Both articles very good but they are not up to date, I have no idea how to integrate them cleanly with the latest version.

[eddyystop]

@ekryski could answer this best, but here is what I know.

A version of feathers-permissions with noteable enhancements has been proved in the wild.

The core team is 6 part-time people and some members are devoting what free time they have to auth and auth docs. This means permissions will be documented and released after auth is 100%. I cannot estimate when that would be.

[poupryc]

+1

[georgeedwards]

@eddyystop @ekryski I don't want to pressure as I know you are a small team, but is there any update on this, or notes of what needs doing / what we might be able to help with.

[eddyystop]

I doubt ekryski will get around to it any time soon. There was a Medium article published on how to use another package to do Feathers repos. @marshall may have a link to it.

[marshall]

@eddyystop gaaah please stop 😆

[TimNZ]

This makes me want to go back to Parse

[TimNZ]

It was a zero value comment, but wasn't a criticism.
What I should have said was, "Let's implement the parse ACL model".

[daffl]

For reference, there are also two great posts, Easy API Authorization with CASL and Feathers and Access control strategies with FeathersJS on this topic.

Most permission and authorization can be easily implemented in a few lines of code with all the flexibility (and without looking for another module, reading API docs, debugging issues and complaining about it) in a hook. All this module is basically doing is this:

const { Forbidden } = require('@feathersjs/errors');

app.service('messages').hooks({
  before(context) {
    const { user, method, path } = context.params;

    if(user.permissions.includes(`${path}:${method}`) || user.permissions.includes(`${path}:*`) || user.permissions.includes(`*:*`)) {
      return context;
    }

    throw new Forbidden('You are not allowed to access this');
  }
});

[TimNZ]

@daffl Thanks. I was hasty in my original comment, having not done a thorough read of all the resources yet.
I'll go through all the docs and blogs and repos and issues before I write anything again.

[musicformellons]

Same here

[poupryc]

i think the best solution would be to create a feathers-casl module but i do not have the knowledge for

[musicformellons]

Yeah, CASL looks really good, but I too find it not easy to integrate and would like it to easily include Postgres integration.

[daffl]

The linked articles will still work with the latest version, the only differences it that the module names changed. So feathers-errors becomes @feathersjs/errors (as outlined in the migration guide).