4 ms·
Defining authorisation rules as part of your application sounds fine to me. Aim for making compilation and deployment of your application trivial. Sounds like
by bearfrieze 11y ago
Defining authorisation rules as part of your application sounds fine to me. Aim for making compilation and deployment of your application trivial.
Sounds like you want a linear hierarchy of roles. Attaching a number to each role and making rules based on that number might be all you need. For example:
Superadmin : 100
Admin : 90
Manager : 80
if (a.number > b.number) a can delete b
- praseodym 11y agoAnd if you want to make that readable, you could use enums or something similar in your language of choice.
- Practicality 11y agoI had a hybrid system at one point that included this "access level" in addition to the roles system. So a person could have multiple roles, but only one access level. The access level was only for admin things like this, so most people were just "users." It works fine, but you need to document what is going on, or at least put some good comments in. You are definitely going to confuse future developers (including yourself) as to why you sometimes check one set of constraints and sometimes another. I got rid of this once the system got more heavily used though, as it's just too much overhead to keep track of two systems. So if you really do plan on staying small it's fine, but if you think this might grow, just stick to roles.