Field Level Permissions - Users-Permissions - Discussion

[NickBolles]

Edited by @derrickmehaffy on 2021/0329

I have morphed this feature request to point at the Users-Permissions specifically to support Field level permissions.

---

Summary

This feature request is for permissions on fields.

Currrently

Currently we have permissions on controller actions by roles. This is good for completely restricting access to certain actions, but there are some big issues with it, especially when paired with Graphql.

Background

We stumbled across this issue with the me() query that I created in #2116. Essentially the UserPermissionsUser GraphQL type exposed the UserPermissionsRole type, which itself exposed the Users array of all users with that role. This would allow access to all of the users with the same role. This is a fairly serious exposure of information if steps aren't taken to mitigate it.

I solved this instance with a custom return type UserPermissionsMe and UserPermissionsMeRole that doesn't have Users on it. But that shouldn't have to be done for every type. Also, this UserPermissionsMe type doesn't get updated with any of the fields that are added to UserPermissionsUser, so currently I have to do separate requests for more fields on the users object.

Huge thank you @kamalbennani and @danielmahon for helping me identify and fix these issues!

Potential Solution?

First off, I'm pretty new to Strapi, so this is just my initial take, and by no means a definitive solution. Please give feedback and suggestions!

I think the best way to solve this issue, other issues, and while adding a bunch of functionality and flexibility, is to expand on the permissions plugin to add field level permissions. I am approaching the field permissions similar to the policy field on the permissions model.

I think there are a few parts to it...

1. Config

I see this as an additional section on the permissions edit page in the Advanced Settings section after you've allowed access to an action. This section could list out the fields and have check marks for what is accessible.

2. Storage

These field permissions could be an array on the permissions model. I think just an array of objects with a field property, and an allow property, at least for now.

3. Enforcement

I think the biggest issue comes down to how to enforce these field level permissions. My initial impression is whenever something is returned by a controller, we run it through a processor for the permissions to omit any fields before returning it to the caller.

It seems like almost everything goes through a controller, so this would be a pretty central change, and help to be consistent.

3b. GraphQL

For GraphQL I think we would need another layer, or if not, it might be helpful.

GraphQL Directives are almost exactly what this is for, and could be a standard directive for every field/type.

Bonus Ideas

Owner concept

Making a owner concept would be really neat. Basically this would apply to any model that has a user on it. If the user ID on the model matches the authenticated user, you would have access to that document, very similar to the me query. Of course we'd have to allow this to be turned off. And I'm not quite sure how this would work, But I think it would be very cool to just say, give me all of my stuff.

[NickBolles]

Exactly! This is exactly what I proposed the "owner" concept for. Maybe it would make sense for this to be a property on the field. So any model that has a relationship to `user` and is marked by the`owner` property would allow the current user to access it. if the user it's related to is their own. I don't think your solution is possible right now without a custom `findMine` controller. This seems like an extremely common scenario though, so something baked into the `UserPermissions` plugin seems appropriate.

…

________________________________ From: PashalisN <notifications@github.com> Sent: Friday, October 19, 2018 7:03 AM To: strapi/strapi Cc: Nick Bolles; Author Subject: Re: [strapi/strapi] Field Level Permissions - Discussion (#2161) If I understand it correctly I think you have the same issue as I have. What is the meaning of relations when for Example: I have a new content type 'articles' and the pre-installed users. If I have 2 users (user A, user B) in authenticated role and each user has for example 2 articles and I want to find (display) only these articles which are related to user A and not just every single article in the database, how can I do that without switching in coding? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2161 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHhrL05CcBbeStlX5t7sLIVa4fb9MxwRks5umb-cgaJpZM4Xspms>.

[EBPIUZH]

So, then I ask you guys (devs) why do you release a version with user roles and permission without having such an essential thing like this. In my opinion it doesnt make sense.
use case:
Imagine, If I have a bank account and I am related to my account with "MY" sensitive data, and any other authenticated user can make a request to all bank accounts, so for what do I need these user permission role thing???
I thought I am wrong with my way of thinking and had overlook something in the admin panel, but these essential thing should be the first thing to think about when I try to understand how user driven data are made for

[EBPIUZH]

another solution could be to make api endpoints more flexible, if I want to have my own articles I should be able to define it like this:
api/user/articles ... this could make sense if you use nonsql databases.

[NickBolles]

You do have a point, we could just add a "my" controller action for everything. That could be a way to do it, which is basically the work around right now, to make a custom controller that forces adding a filter to the query. but we could add it as part of the generation of a model. I think that's a lot less flexible than field level permissions, and it's more of the "owner" concept.

[Aurelsicoko]

I completely agree with all of you about this security issue. Currently, the policy system that we have is great but it only works for REST. I think we could reuse/extend this system and apply it to the field level. Or maybe we should rethink it entirely.

IMHO, the issue is specific to GraphQL. We do not have that kind of issues with REST because the queries are not nested like it can be using GraphQL.

I don't like the idea of extending the UI because the UI has to be agnostic or support the feature both for REST and GraphQL. What do you think if we support a new property fields when you can apply a new level of policy?

module.exports = {
  resolver: {
    Query: {
      bank: {
        description: 'Return a single post',
        policy: ['plugins.users-permissions.isAuthenticated'],
        fields: {
          users: {
            allow: true,
            policy: ['isBankOwner']
          }
        }
      }
    }
  }
};

However, I already see the limitation of this solution... how can we support more than one level of policy? What happens if inside the users field I can access to the bank account, etc.

Imagine a query like thisbank(id: 1) { users { bankAccount { id, name, total } } }... I shouldn't let the bank owner to access to the total of every account in the bank (the example doesn't make sense but you understand the idea behind).

[NickBolles]

@Aurelsicoko thanks for your comments.

I think the idea here is that all of the other plugins respect the core plugins. So for graphql it should respect the user-permissions permissions policies. I think that there was a pull request out there to fix this deficiency in the graphql plugin.

I really think that this should be a field level policy, not a query level setting.
If it's a field level policy it can be a lot more dynamic, e.g. are we logged in, okay then allow, are we an admin, okay, allow, etc.

I'm prototyping a system like this that modularizes policies to a set of functions that can be called to compose a policy for any object in strapi, as well as an owner policy that will look to the model definition to determine which field should be equal to the current user's ID, that can be used from other policies too.

Keep an eye out for a PR, I'll try to have this done by next Tuesday.

[Aurelsicoko]

@NickBolles Oh, I like this approach of field policy. I think we should add the support a new policy attribute in the model instead. So, the GraphQL plugin will be able to easily retrieve policies associated with a field and execute them in order to let the user access to the data or not.

{
  "connection": "default",
  "attributes": {
    "username": {
      "type": "string"
    },
    "email": {
      "type": "email"
    },
    "role": {
      "model": "role",
      "via": "users",
      "plugin": "users-permissions",
      "policy": ["isOwner"]
    }
  }
}

However, I'm worried about the format of our current policy. I would like to keep a generic format of policy for routes and fields if possible.

module.exports = async (ctx, next) => {
  // Do stuff

  await next();
};

[danielmahon]

@NickBolles @Aurelsicoko Might be worth looking into: https://github.com/maticzav/graphql-shield

[jdmann]

I found this thread while searching for a way to customize Strapi so that I can completely separate user or organization-level data from each other, without having to use multiple applications. If users could belong to an "organization" and all access was restricted within that organization, that would seem very useful.