Proposal for permissions in populate++

[feathersjs-ecosystem]

Proposal for permissions in populate++

[eddyystop]

@ekryski has suggested

favorites: {
  include:
    when: {
        permissions: [
          '*',
          'favourites',
          'favourites:*',
          'favourites:*:*'
        ]
      },
    posts: { ... }

[ekryski]

Nice work putting this all together @eddyystop. I'm not entirely sure on population but I'm liking where serializing is headed. This is exactly what I was thinking really:

const serializerPermissions = {
  employee : [
    { permissions: ['payroll-mgr'], serializer: serializers.employee_manager },
    { permissions: 'payroll-clerk', serializer: serializers.employee_clerk },
  ]
}

I'm thinking population really good be the same. In an medium to large app you might have a bunch of serialization and population "policies" but this is still already so much more scalable than having to create one-off hooks for each entity permission role, group, etc.

I'm publishing feathers-permissions later today with some updated docs.

We are allowing only ors on the permissions.

I think that is ok in almost most cases. You must have at least 1 of the required permissions. If you require you can create and conditions by chaining multiple checkPermissions hooks with different configurations.

[eddyystop]

@ekryski I'm setting things up so the client can pass params: { query: { populate: 'a.b.c', serialize: 'd.e.f' }} for populate(/*populations.a.b.c*/) and serializeWithPermissions(/*serializerPermissions.d.e.f*/)

The client can now specify the view it wants to get back, which removes boilerplate on the server.

However some control is needed on the server and this is where permissions on populations comes in.

[eddyystop]

I'm thinking a decent permission structure for populate would be service:schemaName, and service.schemaName:role for serialize.

[eddyystop]

https://github.com/eddyystop/feathers-test-populate-etc is where this is being handled.