Idea: custom required permissions

From reading through the source code for checkPermissions, it looks like there are two significant steps:

1. Map the current hook to permissions which essentially builds out the necessary permissions for the current action being taken, based on the options.namespace and hook’s method and (potentially id.
2. Check those permissions against those in the entity.

What this doesn’t address, is a scenario where the permission is based on the incoming payload, or other request factors e.g. I may have have a user who can update another user to an admin, but not necessarily to an owner. In this scenario, the required permissions step won’t be able to distinguish between these two, as both would be update methods and map to the same required permissions array.

I think there would be a couple of different ways to address this:

• Allow a function on options to override the classify function, or append to it. Not sure if this is too heavy handed or
• Allow a selector option which selects the required permission from somewhere on the hook.params e.g. checkPermissions({ permissionsFrom: 'requiredPermissions' }); and a hook with hook.params === { requiredPermissions: [ 'promote_user' ] }. That way you can just add a hook before the checkPermissions method which would attach custom permissions to the hook.

Would love to get some feedback on this idea / alternative solutions to the overall issue. Cheers!

[daffl]

Could the syntax be the same as a normal JavaScript Array every and some?

service.hooks({
  before: {
    // All permissions
    all: isPermitted.every(
      hasPermissions({ entity: 'user', field: 'permissions', service: 'users' }), // similar to checkPermissions. All these options are optional and would default to these values
      (hook) => hook.params.user.role === 'admin' && hook.data.plan === 'pro', // just returning a boolean
      (hook) => { // returning a promise that eventually resolves a boolean
        const query = { type: 'pro', $limit: 1 };
        return hook.app
          .service('plans')
          .find({ query }, { paginate: false })
          .then(results => hook.params.user.uploads < plans[0].allowedUploads)
        });
      })
    )
  }
});

service.hooks({
  before: {
    // At least one
    all: isPermitted.some(
      hasPermissions({ entity: 'user', field: 'permissions', service: 'users' }), // similar to checkPermissions. All these options are optional and would default to these values
      (hook) => hook.params.user.role === 'admin' && hook.data.plan === 'pro', // just returning a boolean
      (hook) => { // returning a promise that eventually resolves a boolean
        const query = { type: 'pro', $limit: 1 };
        return hook.app
          .service('plans')
          .find({ query }, { paginate: false })
          .then(results => hook.params.user.uploads < plans[0].allowedUploads)
        });
      })
    )
  }
});

[ekryski]

Actually it’s looking more like it could just be this:

// At least one
service.hooks({
  before: {
    all: unless(some(hook1, hook2, hook3), () => Promise.reject(new errors.Forbidden())
  }
});

// All must be true
service.hooks({
  before: {
    all: unless(every(hook1, hook2, hook3), () => Promise.reject(new errors.Forbidden())
  }
});

and then we don’t even have isPermitted. Just any helper hooks for checking permissions/ownership.

@daffl I think that is the opposite of your when hook you were hoping for. So we can have:

• when (synonymous with iff)
• unless (synonymous with iff(isNot()))
• iffElse