Role-pointer column in CLP

[rihadavid]

Would it be possible to implement Role-pointer CLP permission?

Currently we can add a User-pointer column to CLP, but Role-pointer CLP is not allowed.

EXAMPLE:
In my CLP, I need to disable public Find, enable public Get and enable Find for certain Role. But each row has different Role that it should be visible for. It would be solved with a Role-pointer column CLP, but CLP does not allow me to add Role-pointer column.

It seems to my that it might be easy to implement, since Role CLP is possible (just allowing the pointer..). Unfortunately I can't do it by myself, my skills in js are not that good.

[rihadavid]

Any chance that this could be implemented? @flovilmart, seems like you implemented the pointer permissions, do you think that this would be possible?

[flovilmart]

I believe that's possible, do you want to try implementing it?

[rihadavid]

I don't have experience with implementing parse server, I am implementing cloud code functions in javascript for my app, but have no experience with Node.js and parse-server project at all. I am not sure if I could make it :-/ What do you think? Would you give me some hints, maybe?

[natanrolnik]

@rihadavid I didn't have much a few months ago, and I was able to do a few small but incremental PRs in the past just by trying it and going over the project.

Maybe take a look at the User pointer CLP, it might give you some direction; and I'm pretty sure @flovilmart can help you giving some hints also.

[rihadavid]

So, I finally decided to try to implement this.

I have ran into two problems.

1. In DatabaseController.prototype.addPointerPermissions, there is aclGroup parameter, which contains acl-info about the user who did the request, i.e. his objectId and names of roles that he is in. The problem is, that it is names of roles while for querying the objects that comply with the CLP-Role-Pointer, we would need objectIds of roles. Or we'd have to make not CLP-Role-Pointer but CLP-String column containing the role name, but it seems weird to me to enable adding String column to CLP.

2. The aclGroup parameter contains all of the Roles that the user is in and it is part of every user request. This makes me think that assigning many Roles to a user (followers model - my plan was to add a user to other user's 'followers' role when he follows someone) might not be a good idea, considering that user could follow hundreds or thousands of users. I think it would add a big load on server, on every request. What do you think?

If it really is a bad idea using Roles for 'followers model', then I will probably not need this CLP-Role-Pointer feature at all.

What do you think?

[flovilmart]

So, if I understand correctly, for your use case, you'd like that a column 'role' in your object would define what role to allow read/writes.

As you mention, we usually mark roles with their names and not their objectId, that's not too big to overcome, but may require a quite large refactor, or the column could be just identified by a string, the role name. That still implies that you write this role and have it alongside the objects. The design decision behind pointer permissions is that the user would be anyway in the object, so that would reuse the existing schema design to apply security on it.

This ends-up being the same as writing the role name in the ACL, which works properly now.

[mullwaden]

@flovilmart I am having a similar challenge as @rihadavid - I have a class in which I want public Get, but only a specific role may Find (and that role is different for each row). I see two solutions:

• The above approach (i.e. allow pointers in the CPL that point to Roles)
• Add a 'list' option to the ACL

Are any of these realistic? Any suggestions on workarounds? (Right now I have find disabled in the CPL and instead have a cloud code function that returns the list when needed, but this kills a lot of the nice things with parse, live query in particular).

[flovilmart]

We need to investigate properly the ability to use a role column as a pointer permission it seems.

Are you willing to take a crack at it?

[mullwaden]

I have never contributed to a project like this but it would be fun to try. Any pointers as to where I would start? Also I am guessing this would require edits to the parse-server implementation as well as the dashboard, are there any other places?

---

To summarize, the issue is the level of control in the ACL vs the CPL:

What you can set:

• CPL gives Get, Find, Create, Update, Delete, Add field
• ACL gives Read, Write

Who can be set:

• CPL: public, specific role, specific user, pointer to user, master key only
• ACL: public, specific role, specific user, master key only

Looks like either the ACL should be given the fine grained control of the CPL (which will probably break a lot or get a strange syntax) or the CPL should get the pointer to role (seems simpler to me).

[flovilmart]

I would go for the CLP additions, this is not breaking and well understood as modeled upon the user pointer permissions.

The core of the security logic would lie here.

In this method we add the user permissiosn to the query, we should do the same with the roles.

• Roles in the aclGroup are represented by their names, unfortunately, we don't store anywhere the roles by their objectId, which leads to a required refactoring here in Auth.js so we store the roles fully.

• The last step would be to allow passing a role into 'readRoleFields' 'writeRoleFields' the same way we support 'readUserFields' here

What do you think?

[mullwaden]

Makes sense - will try to find some time to give it a shot :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.