Can't use filament with SESSION_DRIVER=database

[kaiserkiwi]

	Version
Filament	v3.0.53
Laravel	v10.23.1
Livewire	v3.0.5
PHP	v8.2.10

Problem

It's impossible to reach the admin panel when I have the SESSION_DRIVER in my .env file set to database as it's the default in Laravel Jetstream projects.
I always get this message:

If I change the value to file everything works fine but then I lose the sessions feature from Jetstream where a user can see what other sessions are active currently.

With #2328 there was a similar issue but the person had file already in their environment file and the problem fixed itself?
It sadly doesn't fixes itself for me. So maybe anyone has an idea what I can do.

[kaiserkiwi]

I'm pretty sure this isn't the solution and this will cause other problems, but if I remove StartSession::class, from the middlewares in app/Providers/Filament/AdminPanelProvider.php everything works fine.

This can't be the solution right? Sorry for the probably dumb question, I'm not a full time backend developer and I don't exactly understand what is happening here.

[thechrise]

This is the correct (temporary) solution. We had our StartSession::class in the kernel.php global middleware group instead of the web middleware group. By commenting out the StartSession::class from Filament's middleware array, you prevent the StartSession::class from firing twice.
I say this is temporary, because as of the time of writing this reply Laravel 12 places the StartSession middleware in only the web group and not the global group. If you have API routes that rely on the auth middleware, they will need to be refactored to use a different auth middleware before moving the StartSession::class from the global group to the web group in your kernel.php.

[ajsultandev]

Did you get this sorted out? I'm facing the same issue after changing session driver to database from file.

[kaiserkiwi]

Nope. Went back to Laravel Nova. I have no time to use a script, that has seemingly no support and doesn't work with basics of Laravel.

[barneyvaughan]

For anyone else ending up here, this is no longer a problem - if it was ever confirmed as one. Just make sure you've run the correct migrations on your staging/production, and set the session_driver properly in your environment.

I ended up here because I was running it on GCP and forgot to set the session_driver to database in the env variables.

[leonnicklas]

@barneyvaughan what so you mean with "set the session_driver properly"?

I am having the same issue still today...

[barneyvaughan]

Hey @leonnicklas !

I hadn't ran the migrations properly so refreshed them on my database.

Then locally I had my SESSION_DRIVER set to DATABASE but my staging and production servers didn't have this setting. I had to rebuild the server with the SESSION_DRIVER environment variable set and it all worked perfectly

[leonnicklas]

@barneyvaughan what exactly do you mean with "I hadn't ran the migrations properly so refreshed them on my database."? The sessions table or some other tables as well? And what went wrong here? Normally the migration comes from laravel itself and shouldn't be different to mine, right?

[barneyvaughan]

Sorry Leon - I didn't see this come through.

I hadn't ran the migrations to include the cache and session tables. Both my ENV needed the session/cache drivers switched to database but I hadn't done that. Once I'd ran those two table migrations on and set the ENV variables properly in my servers settings it all worked as expected.

As a sidenote, not switching the drivers in ENV will cause the system to repeatedly log you out on a multi-server cluster because your session won't be driven by database.

Hope you managed to solve your issue!