Cms: Unable to get database session driver to work

Created on 7 Oct 2020  路  6Comments  路  Source: statamic/cms

Bug Description

When trying to use the database session driver, it prevents the ability to login to the control panel. It seems everything else works, but this is obviously a big item that isn't working for me.

How to Reproduce

Create a local database, and enter your credentials in the .env file
Also in the .env file, change SESSION_DRIVER to database
run php artisan session:table to generate the migration
run php artisan migrate
Attempt to login

Environment

Statamic 3.0.15 Pro
Laravel 7.28.3
PHP 7.4.11
statamic/seo-pro 2.0.14

Install method (choose one):

  • Fresh install from statamic/statamic
bug laravel

All 6 comments

I've figured out why this is happening...

Basically in the session table migration, there's a user_id column which stores the ID of a user if they are logged in. This works fine for database users but becomes a bit of an issue for flat file users as they're not in the database so the foreign key column won't work.

To make this work for Statamic, you'll need to change the type of the user_id column from foreign to string. You should then be able to refresh your database using php artisan migrate:fresh.

Here's what the up method of the migration should look like with the string update:

Schema::create('sessions', function (Blueprint $table) {
    $table->string('id')->primary();
    $table->string('user_id')->nullable()->index();
    $table->string('ip_address', 45)->nullable();
    $table->text('user_agent')->nullable();
    $table->text('payload');
    $table->integer('last_activity')->index();
});

I'm not sure how much this is something that Statamic can fix, maybe it could provide its's own version of the php artisan session:table command with the string type instead of the foreign type or maybe it should just be something that's documented somewhere for others who run into it in the future?

Anyways, that should fix your problem for the time being.

Oh, man! That makes a ton of sense. Thank you for looking into this, I appreciate it a ton!

No problem!

Think this should stay open so we can figure out the "right" way to solve.

That's right enough. If you're using DB users then the ids will be ints.

Perhaps we could write a migration that makes that DB change?

Was this page helpful?
0 / 5 - 0 ratings