How to distinguish admin users from normal users?

Almost every platform that has been created they have the need of users with more than one "type".

1. One which are actual users with normal privileges. The USERS.
2. And the ones who have special privileges. The ADMINS.

Admin users have special privileges that only they should have and not anyone else. Otherwise, if one user can manipulate data of another without there consent then the platform is a mess.

I found it always challenging to design a single database with solves the need of both users.

• Should I have a type of the user stored in my database?
• Should the first user who has registered on the platform would be the "admin user"?

I want to come to a collaborative conclusion about what is a better approach and why?

Comments

[John Alcher]

At the bare minimum, I have a users, roles, permissions, and permissions_users. Here's a crappy diagram I made (sorry for my subpar UML skills lmao):

[rhymes]

Hi John!

Usually it's easier to attach permissions to roles than to users, because then your permissions_users table would explode in size (every new user has to have all its default permissions copied in the system).

It also makes it harder to add new permissions, because you have to create a row for each user in the system.

So, let's say that tomorrow I introduce a new resource in the system, with a set of default CRUD permissions, what happens to the users? Can they work on that resource by default or do I have to create 4 permissions multiplied by the number of users in the systems?

What if I want to change the read permission for all the users with a role X? In your schema I have to go to the DB, load all the users with that role, and edit their corresponding read permission.

If instead roles are attached to permissions I can just edit one line :-)

Another approach I like it's Pundit's, in which permissions are inside the business logic, because they might be granted only if the user passes a complex test. Let's say for example that you want to grant access to a resource only if a user was created in a date range and if they have 5 points accrued in your system.

By having permissions written in stone in a table you might have to modify them at runtime by calculating if the user passes the test, then add the specific permission and then let the user pass through. But what happens if the users the day after don't have the 5 points anymore? You are allowing them through even if they shouldn't be allowed. Yes, you could setup a callback for each time they lose a point but... well you know, it's going to explode pretty soon in complexity.

If, instead, permission are part of the business logic, you can easily test them in isolation and have them as complicated as you wish, without relying on a "switch table".

Hope this offers you a possible alternative in case you have a more than trivial setup. Let me know if there's something that's not super clear!

[John Alcher]

Hi!

I really don't have much to add, your approach is much flexible and clearer. I actually wrote a couple sentences how I used permission_users for "one-off" permissions, but then I deleted it after realizing you've explained it already by giving permissions through the business logic (policies and gates in Laravel). Which kind of defeats the point of my permissions_users table. I stand corrected!

[Mohammad Aziz]

Thanks, John. The diagram helped me to have a foundational understanding of the things.

And they are definitely not crappy by the way. 😄

[rhymes]

Hi Mohammad!

In my experience it really depends on how complicated the thing you want to build is.

I think the simplest is having a list of users and a list of roles. Each user can have roles. Users with no roles are regular users, users acquire super powers for each role they have (admin, editor, etc. etc.). Usually a user with the admin role doesn't need other roles, but that depends on what meaning and logic you attribute to each role.

I remember an app I did for a client where they wanted store managers to have a set of permissions, admins to have another set of permissions and supervisors to be completely read only but with a wide spectrum of read permissions on the systems.

What permissions a role has is entirely dependent on your business logic.

Should the first user who has registered on the platform would be the "admin user"?

Nope, usually the admin or creator of the platform has some sort of admin role. It should be a person whom you trust, not "the first one".

FYI: most stacks have libraries that already solve this issue, by handling users and admins, the concept of current user and roles and permissions. Some are just binary (a user is either a user or an admin), others are more granular (a user can have a list of roles).

So, to recap: you have users that have certain roles and then in your business logic you decide which permissions each role has on each "object" they are allowed to access.

[Mohammad Aziz]

Thanks, rhymes for your simple and clear explanation.

Having just binary concept of user's roles might be helpful in some situations but I really like the idea of having a list of roles. It almost works like an authorization step for the entire system and it is scalable too.