Level 75
A user is a user no matter the role, so use authentication for log in and authorization to determine what that person (role /s) can or cannot do.
1 like
Apr 25, 2024
5
Level 1
Why many Dev do not like the idea of multiple guards in Laravel?
Initially, this is just a small discussion. When he wanted to try multiple guards because I was working on a project that involved a lot of people, the solution in his opinion was to set different Tables because Different data i need from it. But I saw that many people do not like this idea. Even Laravel Daily, in one of its old videos, have other suggestions to avoid this way.
It may be complex in some cases, such as Jetstream, or easy, such as Breeze, so I would like to know how you to see This Concept?, when use it? And why not?
Notes:
. I mean By multiple guards, I mean the presence of multiple tables that manage the login, and I do not mean permissions and Roles.
. I'm just a hobbyist, but I'm curious, because I tried Breeze and it was more like a game to understand how the code works there, and also you can manipulate it until you make it accept from one form and so on.
Level 122
Alternate guards might be used where a method of logging in is required that is not eloquent based. There is absolutely no point in adding a guard just so that you can separate the users into different tables.
It just adds unecessary complication and duplication of routes, forms, controller and models.
Multiple guards are often seen as a way to differentiate between user types, but that is just confusing authentication with authorization. Authentication should be purely knowing who the user is. You can then use Authorization techniques to understand where they are allowed to go and what they can do.
1 like
Level 1
@Snapey But what if in some other cases, for example, there is a huge difference in the tables, as is common in this topic. School management system: I need simple information from the admin, while I need more information from the school, and so also with students or any other workers. Should we make one Table 'users' then leave these fields null here?
. I'm convinced that Mulit-guards, is just complexity but in some cases I feel it is incorrect to have many empty columns.
Level 122
@Thomas_Emad move those things to a profile table. If they are a student, then they will have a student_profiles table. That additional information is not relevant for authentication.
1 like
Level 80
@thomas_emad It’s not “liked” because it just causes more problems than it solves.
A user is a user. What that user can and cannot do, should be controller with roles. If a user can access an admin panel, they should have an “admin” role.
It also becomes a pain when you have more than just “admin” users and “regular” users. What happens if you want to introduce some sort of moderator panel? Do you create a third table to hold data for those type of users? What happens if you want to promote a moderator to be an administrator? You’ve now got to delete a row from one users table, to add them to another. But then that’s going to be problematic if you’re using foreign keys. Say comments have a moderator_id column to designate which moderator moderated the comment. Well that foreign key constraint is going to prevent you deleting the moderator who you’re trying to promote to an administrator.
Then with guards, it becomes a clusterf**k when authenticating users. It’s easy if a route should only be accessed by only one type of user, but then becomes a pain when you want a route to be accessed by multiple user types, because you can’t use “or” conditions with middleware to do something like auth:moderator OR auth:administrator. You’ve then got to create multiple login forms, registration forms, password reset forms, etc.
All of these pain points above can be solved by just having a single users table and then using roles to determine what each user can and cannot do.
2 likes
Please or to participate in this conversation.