Replies: 1 comment
-
Make a debug and get deep |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi there!
I have some doubts about this package, more specifically about the use of guards, I really didn't understand this part of the documentation. Basically I have an app that has routes that use standard laravel authentication with 'web' guard and some API routes that use sanctum through token (I don't use sanctum for SPA).
That said, the system has some roles to granulate users' access to resources, but a question recently came to my mind regarding this issue of guards. In all roles defined in the system, the guard_name is as 'web' and everything works normally, users have access only to the resources released through the roles assigned to them in the web routes, but in the api routes, which uses the 'auth:sanctum' middleware (or ie the guard sanctum) the defined routes also work normally, shouldn't it be the other way around? Shouldn't the package see that the current route is in a different guard context (in this case the guard "sanctum") and not grant access? Because the roles used in the api endpoints also have the guard_name 'web'.
I looked in the package's source code and the middlewares available seems to use guards only to verify that the user is authenticated in the defined guard, and not to search the database for a role or permission with guard_name = ?.
If I set a guard_name as the second argument of middlewares or blade directives the package seems to block access, which makes me think that guard_names are only used if I manually specify which guard to consider, does that make sense? is the expected behavior of the package? or the package "should" check this automatically?
Please help me understand this.
Beta Was this translation helpful? Give feedback.
All reactions