User role and permission in laravel

PHP
1

Greeting to my Seniors,
Im trying to learn Laravel framework, for project having multi-authentication user having role like super-admin, admin, manger and user.

  1. Super-admin: can view all data of all user (admin, manger, user) can modify,delete their data, create user with all roles
  2. Admin: can view all data of all user (manger, user) can modify,delete their data, create user with all roles excpet super-admin.
  3. and so on for others role.
    im following tutorial on internet where instructors:
  • Create separate table for user
  • Create separate table for role
  • Create seprate table for permission
    and inter-link them with forgeign keys.

Cant we simply create user table with column roles which will have user roles (like:: super-admin,adminā€¦etc) on creating new user
auth: if user role=== super-admin{
create new user
delete user
view post of all user
}
Please englight me why we need separate table for user, role, permisson

2

So the general rule of thumb will be ā€œdatabase normalizationā€. This isnt really a Laravel concept, as it is a general database concept.

If every Admin has the same permissions, you dont want to store the permissions over and over in the table. Consider this: I want to store if someone has permission to modify 3 different pieces of data (A,B,C). I will call those permissions mA, mB, and mC.
I will have 3 users; Alice, Bob, and Charlie.
Bob and Charlie are my admins.
All admins can modify A,B, and C.

I could store them all in one table:

Name Email isAdmin mA mB mC
Alice alice@example.com 0 0 0 0
Bob bob@example.com 1 1 1 1
Charlie charlie@example.com 1 1 1 1

Butā€¦ thereā€™s not really much point in it, is there? If I know Bobā€™s an admin, I already know he can modify A B and C because that was one of my rules. So I dont really need to store that information about him; i know heā€™s an admin, so he has mA, mB, and mC. We could leave those three fields out of the database.

Name Email isAdmin
Alice alice@example.com 0
Bob bob@example.com 1
Charlie charlie@example.com 1

Great. Now i have stored all the information i need.

But maybe I make this configurable. Maybe the Super Admin can decideā€¦ no, Admins shouldnt get mB.

Well i need to be able to change that somewhere where the system knows my rules have changed. So iā€™ve definitely got to write mB in somewhere. But i dont really want to have to write in a 1 or a 0 for EVERY user, that uses up a lot of space if i haveā€¦ a million users, and if the superadmin changes his mind later, i would have to update a million rows to make sure the change was made. That seems like a lot of effort.

So thatā€™s why we do it in multiple tables.

Lets say the super admin has decided admins get mA and mC, but not mB.
I could write out a single table called Users:

Name Email isAdmin mA mB mC
Alice alice@example.com 0 0 0 0
Bob bob@example.com 1 1 0 1
Charlie charlie@example.com 1 1 0 1
SuperAdmin sa@example.com 1 1 1 1

but thatā€™s a lot of numbers. The information i want to store is ā€œAdmins should have mA and mC, but not mBā€. Notice i didnt mention Bob or Charlie by name there. The information I want to store is about the ROLE, not the individual USER.

So at this point, I need a new table. Roles. That way, I can have my role table (Note: Iā€™m going to add an ID field here):

ID Name mA mB mC
1 User 0 0 0
2 Admin 1 0 1
3 Super Admin 1 1 1

Iā€™ve now stored all the information about roles I need. And my User table can remain pretty simple:

Name Email Role
Alice alice@example.com 1
Bob bob@example.com 2
Charlie charlie@example.com 2
SuperAdmin sa@example.com 3

A single number in the Role column tells me all i need to know.

So why does it suggest 3 tables to you?
What itā€™s trying to do is create the idea of flexibility. If later on, you decide you want to add a new permission, youā€™d have to modify the table, and the queries related to that table throughout the code, and etc.

If however, you make it ā€˜genericā€™, you can more easily adapt your code.

What theyā€™re probably trying to suggest (I cant see your tutorial) is the idea of a Join table.

Namely:

  • A User has a Role
  • A Role may or may not have one or more permissions
  • The list of permissions is not hard defined at time of creation, and/or may be added to by external items (addons, plugins, patches, etc).
2 Likes
3

Wow, your explanation made crystal clear for my all doubts. Thank you for your effort and time

1 Like