Always check for permissions, not for roles... does it apply for every case?

[martinsnajdr]

I understand the principle that roles are just grouped permissions, and permissions allow you to very granularly assign what a given role can do within an application. But now I'm dealing with a situation where I have three roles (admin, tenant, landlord) and they have to see very different screens, have differently built navigation etc, dashboard. And suddenly I find it very disadvantageous to somehow tie it to permissions, because in principle I don't need to test if the user can edit, delete etc, but I need the app to behave differently for the role.

E.g. an admin can create a housing unit, but it will show a form where everything can be clicked in one place. Whereas a landlord is setting up a housing unit through some multi-step process that cannot be accelerated. And in principle, there is no overlap in permissions between roles. The admin, on the other hand, never sets up a housing unit through this multi-step process. And by having those individual roles so strictly separated, then it doesn't seem to me to be a good idea to actually create permissions that will always be assigned to that one specific role and never reused.

What's your opinion on that?

Thanks!

[drbyte]

There are indeed times when testing for a role makes better sense. Nothing wrong with that.

The principle of coding for permissions-first instead of roles-first helps avoid over-granting access when things haven't been thought through fully. Many times the "actual" need is really permission-based, not role-based, and thus coding for permissions-first helps avoid complicated rewrites to both core code and for UIs.

But there are definitely times when roles are the best "check".

An example where I use roles a lot is route groups, especially if the application doesn't really need alternate "guards" for those groups. But then within those route groups I may wrap subsequent groups, or individual routes, in permission checks specific for those routes.

And sometimes in a UI it may make sense to only show a certain "block"/section if a certain role applies, but then within that block do more granular permission checks for certain things to see vs edit, etc.