Permissions hierarchy #26
-
|
Hi @JonPSmith First I want to say thank you for your great work! I have a question regarding permissions. Very often e.g. in CRUD applications, permissions related to a certain feature are organized in some hierarchy. Usually it is something like that: Read <- Write <- Admin, where 'higher' permission includes the 'lower' permissions. In such case if an InvoicesAdminRole has e.g 'InvoicesAdmin' permission attached then it has access to all stuff marked/decorated with InvoicesWrite or InvoicesRead permission. AuthP has a flat structure of permissions (or maybe I missed something), so to achieve the same behavior I would need to attach all 3 permissions to my InvoicesAdminRole. Is that right? Do you think it's worth to make code a bit more complex to achieve similar behavior? Do you think it would be helpful for admin users in roles administration? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Hi @damianostre, I can answer because I tried the Read <- Write <- Admin and it didn't work out that well. Here is why I say that. I was asked to build a large multi-tenant application and they wanted a way to change what a Role did dynamically, which is where the Roles / Permissions idea came from. At that stage we were worried about how many permissions we might have so many permissions that we could reach the cookie limit of 4000 bytes. Therefore we used the "higher" approach has something like this:
The downside of this was it was really complex to create these permissions - in the end I defined the Permissions by group (XXX) and type (Read) in a json format and then ran a simple application to generate the Permissions. It did reduce the number of Permissions in a Role, but it wasn't so clear, especially it you had function-specific enums because it hard to know what other things they allow. My takeaway from this project was that Roles and Permissions (enum) work very well, but using the "higher" approach for the Permissions was a bad idea. We never got more than 250 Permissions (enums), so the cookie size wasn't an issue (enums are stored Unicode char - so 1000 only takes up 2000 bytes), but the complexity of the "higher" approach was a pain to understand and use. Also, because of the Unicode chars for enums a Role just has a Unicode string holding all the Permissions - have a look this document on how you could implement a simple select Permissions to go into Role (apps with hundreds of Permissions would need a search / filter which is why the I hope that helps. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @JonPSmith, thanks for a detailed answer! |
Beta Was this translation helpful? Give feedback.
Hi @damianostre,
I can answer because I tried the Read <- Write <- Admin and it didn't work out that well. Here is why I say that.
I was asked to build a large multi-tenant application and they wanted a way to change what a Role did dynamically, which is where the Roles / Permissions idea came from. At that stage we were worried about how many permissions we might have so many permissions that we could reach the cookie limit of 4000 bytes. Therefore we used the "higher" approach has something like this:
The downside of this was it was really com…