Independent Authentication Guard - log in issue

[web541]

Hi, I'm testing out to see whether it's possible to add Statamic to an existing Laravel app, but have the Laravel users separate (in a DB) to the Statamic users (in files) as we would only have one or a few users actually editing the Statamic side through the /cp.

I've been following this guide exactly: https://statamic.dev/tips/using-an-independent-authentication-guard but I seem to be getting this error:

call_user_func_array(): Argument #1 ($callback) must be a valid callback, first array member is not a valid class name or object

After some further digging, it looks like it was still trying to use the eloquent driver and was expecting a 'model' in the config/auth.php providers array for the statamic provider which didn't seem right to me:

'providers' => [
    'users' => [
        'driver' => 'eloquent',
        'model'  => \App\Models\User::class,
    ],

    'statamic' => [
        'driver' => 'statamic',
       // expecting a 'model' here...
    ],
],

However, I figured out that it was still using the eloquent repository in config/statamic/users.php, so swapping this over to file does fix the error and the /cp login form appears to work except that it doesn't actually log the user in (despite the user existing in the /users directory) and acts as if the credentials could not be found. This part wasn't mentioned in the docs, so I wasn't sure if this was a necessary step, but figured it was worth a shot.

'repository' => 'file',

All of this was tested on a brand new Laravel install (v11.15.0) with Statamic installed using this guide https://statamic.dev/installing/laravel before I try it on a more developed project.

Any thoughts? Thanks!

[huuvan20]

The same issue for me which is the login page accepts the credentials (which is the correct one) but nothing else happens after that. The login form is empty without letting users in.
@web541 Have you been able to fix that yet?

[jerwre]

I'm experiencing the same issue. I'm installing statamic into a fresh laravel installation (laravel.build) following the docs, and I change to use file for users in configs. Create a new user via CLI (user file gets created), and when I try to log in I just get sent back. The form does not shake as if I entered the wrong credentials.

When I installed a new project with the statamic cli, I can switch between file and database, and I can set it up to use file for cp/statamic and database for users in general. I copied over the auth and users config files to the first project just in case, but it did not help.

[duncanmcclean]

I've just tested this again...

I cloned the repository @web541 made and registered a user in Jetstream and created a user with php please make:user and I can login to Jetstream/Statamic without any issues. I haven't made changes to any files, apart from creating a Statamic user.

I'm afraid I'm out of ideas. If I can't reproduce it myself, there's not much I can do to debug. Sorry! 😬

[web54]

just here to say : it is not me (@web54 ) but @web541 who is the author of this repository

[duncanmcclean]

Oops, sorry! 😬

[jasonvarga]

That demo site worked perfectly for me too.

• I could log in to the front-end with the DB user that gets seeded ([email protected] / password)
• I could make a Statamic user with please make:user and log into /cp with it.
• I am logged into the frontend and cp with different users at the same time.

I'll look into some other things though.

[jasonvarga]

As for the call_user_func_array(): Argument #1 ($callback) must be a valid callback, first array member is not a valid class name or object error in the original post, I was able to trigger this.

• Install Laravel
• Install Statamic into Laravel
• Configure the separate auth guards.
• Don't change the repository in config/statamic/users.php.
• Create a Statamic user with php please make:user

Setting the repository to file makes the error go away.

In my case though, it worked fine at this point. I wasn't able to get the "doesn't actually log the user in" behavior.

I've update the Laravel install and separate auth guard docs in a couple of places to make some things clearer.

[web541]

Whoops, just reposting here..

Thanks for looking into this! Just curious, what DB_CONNECTION you've been using @jasonvarga @duncanmcclean ? I've been using mysql this entire time and it would appear that's where the issues are coming from (I probably should've made that more clear in the .env.example). I just randomly tried it with sqlite, seeded using the default user and everything worked perfectly! Was able to log into both Laravel and Statamic /cp simultaneously with two different users from DB and file repositories.

I looked into this further and it could be related to mysql and session management. In the .env, this works:

DB_CONNECTION=sqlite
..
SESSION_DRIVER=database

And this also works:

DB_CONNECTION=mysql
..
SESSION_DRIVER=file

But this doesn't work (and this is where I get the "doesn't actually log the user in" behavior):

DB_CONNECTION=mysql
..
SESSION_DRIVER=database

I had a suspicion this might've been the case as when I attempted to log into the /cp, it logged the Laravel user out (in addition to the form not jiggling for wrong credentials and instead just flashed). Any idea why mysql connection and the database session driver might not be working together?

I have noticed that in the sessions table, the user_id becomes null which may have something to do with it (not 100% though), but when it works using one of the first two .env combos above it the user_id column is either filled with the Laravel user_id or Statamic user_id (guid from file) depending on who has logged in first.

@huuvan20 were you using mysql also? If so, would you be able to try what I did above and see if it fixes it for you?

Side note - either way (when it is working), logging out of the /cp also logs out the Laravel user. Is this intended behavior? I'm guessing so based on the single session.

[duncanmcclean]

Interesting!

I think we were both probably testing with SQLite. When I swap SQLite for MySQL, I see the issue (finally! 🎉).

Can you try making the user_id column on the sessions table a varchar, instead of an integer and let me know if that fixes the issue for you?

Side note - either way (when it is working), logging out of the /cp also logs out the Laravel user. Is this intended behavior? I'm guessing so based on the single session.

From what I can tell, while probably not ideal, I don't know if there's much we can do about it.

When you logout, Fortify and Statamic invalidate & regenerate the user's session. Since the user only has one session, they're logged out of both guards.

[web541]

I think we were both probably testing with SQLite. When I swap SQLite for MySQL, I see the issue (finally! 🎉).

Definitely my fault, I should've made that more clear!

Can you try making the user_id column on the sessions table a varchar, instead of an integer and let me know if that fixes the issue for you?

Yep, this has fixed it for me! It appears to take longer to log into the /cp than Laravel, but I think that's more likely my setup than Statamic.

From what I can tell, while probably not ideal, I don't know if there's much we can do about it.

Yep fair enough, it's very minor anyway and probably wouldn't cause many issues (if any) day-to-day so can easily put up with it.

[duncanmcclean]

Great! We can likely just mention in the docs that you may need to change the column type. I've added it to our docs repository: statamic/docs#1475

[AtmoFX]

@duncanmcclean
If i am not wrong, the /database/migrations/ folder contains a file 0001_01_01_000000_create_users_table.php that is installed when creating a new site. Inside that file, I can see $table->Id(); for table users.

Would it not prevent this issue from arising, had it been $table->Uuid('id')->primary(); instead?

Changing it removes the default value on the id column, so something must be added.
The foreign keys on user_group and user_role would need to be $table->foreignUuid('user_id')->constrained('users')->cascadeOnDelete(); in the statamic_auth_tables.php migration file too.

[duncanmcclean]

Would it not prevent this issue from arising, had it been $table->Uuid('id')->primary(); instead?

I haven't tested it myself, but potentially? Although, I don't know that everyone will want to change their database users to use UUIDs to fix the Statamic CP.