Multiple panels login issue
I have 2 panels
/admin
/client
the user that im testing right now can access client
, but not admin
if i login in this route /client/login
all works
but if i try to login at /admin/login
it says:
but this is wrong! the credentials DO match with our records, what happens is that the user cannot access that specific panel.
i think the message should be clearer "you cannot access this panel or something like that", or if is on purpose like this, let at least the developer modify it somehow. can i modify it in a quick way, or is rather more complicated than it seems??
thanks in advance π5 Replies
Are you sure? Are you using different auth guards?
havent modified the guards, so i guess im using web for both. i should change it?
I've been struggling quite a bit with this exact situation. My end users don't go to the right login screen, and then they get a confusing error and reach out for support.
I need to figure out a way to tap into the login process, check their role, and redirect them to the correct panel, rather than returning the confusing credentials error. Would welcome any advice on how to accomplish that.
I've been digging into this today and I think I've got the issue resolved in my project. Wanted to share what I found in case it's helpful.
This code exists in
Filament\Http\Middleware\Authenticate
:
and then for some reason it exists in a similar way in Filament\Pages\Auth\Login
:
I believe this is causing an issue where users who can only access one panel based on their role, are being given an error about their credentials because they can't access the panel. I opted to create a new LoginResponse class that redirects the user to the correct panel and I commented out the code above.Could you not just handle it in the canAccessPanel() method on the User model? Kind of a fake middleware. May be too late in the lifecycle though. Not 100% sure.
Just seems like you need the user to be logged in before redirecting.
Yeah that's what I've been dealing with. I think the canAccessPanel method is too late in the lifecycle. I think one of the above methods is catching it before it ever gets there. The
throFailureValidationException
is a very confusing error for this specific edge case.