Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

garrettmassey's avatar

Filament 419 on every request ONLY when "SESSION_DRIVER=database"

In my application, running Laravel 12 and Filament 3, I have an issue that when the .env file's SESSION_DRIVER value is set to database, every post request in the application returns a 419 page expired error, but if I change the session driver to be file instead of database the issue resolves.

I cannot for the life of me figure out why the session driver isn't working with the database option, any ideas?

0 likes
4 replies
joelbladt's avatar

In this case typically the CSRF token is invalid or the session cannot be read properly.

Since switching to file works fine, it clearly points to a problem with the database session handling, not the CSRF system itself.

1. Is the sessions table present and correctly structured?

Bacause Laravel needs a valid sessions table for database session driver to works correctly.

php artisan session:table
php artisan migrate

You should have columns like:

  • id (string/uuid)
  • user_id (nullable)
  • ip_address (nullable)
  • user_agent (nullable)
  • payload
  • last_activity (int)

2. Database Connection for Sessions Is Working

  • Ensure the DB_CONNECTION in .env is correct.
  • Test if session rows are inserted on request. You can add \Log::info(Session::getId()); in a controller and check if the session appears in the sessions table.

3. Session Middleware Order and Kernel Check

Ensure these middlewares are present in the correct order in bootstrap/app.php:

<?php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__ . '/../routes/web.php',
        api: __DIR__ . '/../routes/api.php',
        commands: __DIR__ . '/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->web([
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

Missing or misordered middleware can cause Laravel not to read/write sessions correctly.

Final Tip: Use Laravel Debugbar

Install Laravel Debugbar to see session content in real-time:

composer require barryvdh/laravel-debugbar --dev

Then check if session is being persisted between requests.

garrettmassey's avatar

@joelbladt Thank you for the thorough reply! To answer your questions:

1. Is the sessions table present and correctly structured?

Yes, the following is my up() method on the migration for creating the users and sessions tables:

and when I run php artisan migrate:fresh to have a completely fresh database, the sessions and users tables appear as they should.

2. Database Connection for Sessions Is Working

The database connection does work, as I am able to use Tinker to create rows in the database, I then run php artisan make:filament-user to create an admin user to login, and that works just fine as well.

When I try to add logging to the Login.php livewire component class (since I am using Filament, this I believe is the default class to handle authentication), nothing is logged, it seems that the class isn't being reached / triggered, and is blocked because of the 419 error.

3. Session Middleware Order and Kernel Check

My bootstrap/app.php is identical except for the namespacing of the middleware for VerifyCsrfToken and EncryptCookies:

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__ . '/../routes/web.php',
        commands: __DIR__ . '/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->web([
            \Illuminate\Cookie\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            Illuminate\Foundation\Http\Middleware\VerifyCsrfToken::class,
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

After checking all of these items, and then running php artisan optimize:clear and refreshing the browser / clearing the cache and cookies, the 419 error still persists.

Edit:

I should also mention that this is my current .env setup for the session:

SESSION_DRIVER=database
#SESSION_SECURE_COOKIE=true
#SESSION_COOKIE="atlas_session"
SESSION_LIFETIME=120
SESSION_ENCRYPT=false
SESSION_PATH=/
SESSION_DOMAIN=null
garrettmassey's avatar

@joelbladt Update: I installed Laravel Debugbar, and when I check the session_attributes the _token value changes between the page loading and the post request/response, not sure if this is what you meant by if the session is persisted, but here is a snapshot of the info:

Login page

request_cookies:
array:2 [▼
  "XSRF-TOKEN" => "sOCjDBcD7sP75VFHNljCrpA6awseXtz4ju4vq1p4"
  "atlas_session" => "1Ja7SdlUlClE1BOsZGggzks8jC5LvWKcb2WdeTpT"
]

session_attributes
array:3 [▼
  "_token" => "Se8wiDspsASHrVrk6qsRmDfvlvGwxi8QwlicS5bR"
  "_previous" => array:1 [▶]
  "_flash" => array:2 [▶]
]

After submitting post request / receiving 419 error:

request_cookies
array:2 [▼
  "XSRF-TOKEN" => "Se8wiDspsASHrVrk6qsRmDfvlvGwxi8QwlicS5bR"
  "atlas_session" => "1Ja7SdlUlClE1BOsZGggzks8jC5LvWKcb2WdeTpT"
]

session_attributes
array:2 [▼
  "_token" => "iqm9lZPjVNMJhaCpxAIXO9YjyfogUqLprtvBuKkB"
  "_flash" => array:2 [▶]
]

I hope that helps.

garrettmassey's avatar
Level 6

I believe the issue was related to the sessions table migration, as I had accidentally changed the id column from string to uuid. After changing it back, migrating again, and clearing items, it seems to be working now. Very strange!

Please or to participate in this conversation.