Login redirects to it self after successful login - in laravel 9.x

[monzer15]

i have just installed a fresh laravel project and installed filament package, there are no console errors and authentication is working fine,
but after a successful login the page just redirects to login again ,Does anybody have any idea how to diagnose the issue?

[danharrin]

It's likely a server configuration issue. Have you used Livewire on the server before?

[jcrodriguezt]

Hello,
I'm having almost the same issue here.

Key observation is that if I get a fresh install with breeze and on top of it filament, it works. But, if I intend not to use breeze, I can make authentication work with login routes and everything. The thing is that when I get filament installed normal login stops working and Filament too.

I can tell that authentication succeeds because I can dd('login ok') in my LoginController

Same thing after Filament::auth()->attempt(...........) returns true in the Filament Login class.

So my question will be the same as@monzer15 --> Does anybody have any idea how to diagnose the issue?

Any kind of help will be appreciated.
Thanks

[jonrmitchell]

I was encountering this too and made it stop by:

1. publishing the filament config php artisan vendor:publish --tag=filament-config and then
2. commenting out the EncryptCookies::class middleware from the filament.middleware.base array of filament.php (currently line 321 for me)

Not really recommending it as a course of action but try it and if it helps, it should be a clue for someone to figure out what is actually going wrong.

[diegogit03]

works, but it is secure?

[jonrmitchell]

Nope, don't do it on real systems! I just meant it as a lead for someone else to investigate further.

[diegogit03]

Anyone solved this?

[jcrodriguezt]

What was wrong with mine, is that since I was using a custom, already existing Users table , I was able to solve it by implementing the getAuthPassword() method to use my password field instead of the "password" field. Other thing is that password hash should be the bcrypted version of my already existing password table in my application.

/**

• Override required, otherwise existing Authentication system will not match credentials.
• This goes inside your CustomUserModel.
• @return mixed
  */
  public function getAuthPassword()
  {
  return $this->userPassword;
  }

[damms005]

If you are using multi-tenancy like me, it may be an issue with your canAccessPanel() and/or canAccessTenant() like I had in my case.

Fix for me was to hijack the redirect loop and logout the currently authenticated user, like this:

Route::get('/login', function () {
    auth()->logout(); // This helps when admin mistakenly logs in to customer panel. Without this, they enter a redirect loop.
    return to_route('filament.customer-backend.auth.login');
});

[TomEasterbrook]

I know this is an old thread, but in case anyone using multi tenancy and they're still having issues, I found that having custom routes that share a path with the panel for example at the root of your panel this problem can also occur. In my case, the panel is / so having my custom login at /login caused this to occur

[henryonsoftware]

Got the same problem. I login and it can generate the session(tried both file and database), but the page will be redirected to login page again.

[abdulhameednabhan]

i faced same do you still face that?

[henryonsoftware]

No, my problem is our team custom the EncryptCookies to auth the users on another repo(Laravel 5.7) - it's not using the prefix on cookie.

[mecha]

If disabling the EncryptCookies middleware in the admin panel provider suppresses this problem, try adding that middleware to Livewire's update route instead:

Livewire::setUpdateRoute(function ($handle) {
    return Route::post('/livewire/update', $handle)->middleware([
        EncryptCookies::class,
    ]);
});

[sojkadavid]

I had the same problem, but the solution was very case-specific.

I was using database as the session driver, but I've changed users.id to ULIDs (not int), but I didn't change the foreign key in sessions.user_id. Surprisingly this didn't trigger any issues while using SQLite, but did trigger an error with MySQL. So all the session rows in the database had user_id = null which made the login impossible.

Had to change the datatype of sessions.user_id to the correct type and it started working again.

[JemCdo]

Thank you, Worked for me.
I had same problem when using ULID's instead of int.

[arxjei]

I ran into the exact same problem. I have both admin and professor panels. I think Filament is a bit prone to this kind of error because it essentially runs within the root of the Laravel app.

In my case, the issue was in a widget where I accidentally typed:

getUrl(panel: 'panel ')

Notice the extra space at the end it was wrong. This little typo almost cost me a whole day of debugging 😅.
double-check your panel names and getUrl calls. even small mismatches can break things silently.