Framework: [5.4] Can't keep user logged in since 5.4

[v-stein]

• Laravel Version: 5.4.6
• PHP Version: 7.0.13
• Database Driver & Version: MariaDB 10.1.21 - MySQL 15.1

Description:

I had an application made with Laravel 5.3 that was running fine, but after upgrading to Laravel 5.4, every time we authenticate, it goes fine and we have access to user informations :

{"id":X,"name":"Foo","email":"[email protected]", . }

The thing is, it is not really logged in as when we want to access a protected view that this user would have access to, it redirects on the login page.
I checked a fresh install of Laravel 5.4 methods of authentication and can't find any difference between application and this fresh 5.4 application.
Moreover, it seems that the User object is getting a null value inside the middleware that protects the routes.
So if someone could tell me where this problem comes from, it would be really helpful,
Thanks.

[movingSone]

Hi @vTripes
Did you follow upgrade guide? First thing it gets on my mind is that Sessions, had similar issue few days ago.

[v-stein]

I did checked the sessions settings but I can't find anything related to the problem, and the application actually running with Laravel 5.3 works fine with the same config.
It seems that the redirection loses the authenticated user...

[datashaman]

Check your clock hasn't gone skew. Sync your machine with an NTP server. Open your browser and look for the relevant cookie that holds the sessions together. Make sure it's pointing to the correct domain, and it has the correct lifetime (expiry). Double-check time zone settings.

[v-stein]

No, it is still running as intended, I'm sure it has nothing to do with it.
As the 5.3 and 5.4 app versions are both on the same server, it sure can't be, and i checked it to be sure.

I keep thinking that it might be the refactoring of authentication method that broke the middleware. On routes that aren't protected by a middleware that verifies the user is correctly authenticated it works fine.
Are there undocumented changes that could be the reason of this trouble ?

[SiNONiMiTY]

Try checking the ExceptionsHandler.php file. There is an authentication check at that file and it redirects to the login page if it fails. Might be a good place to start looking.

[v-stein]

Checked it and seems like it is not what fails.
As a reminder, once you log in, the user has access to the home page (protected by the auth middleware), but every other action returns a 401 HTTP status (Unauthorized) and it redirects to the login page.
Meaning that it can authenticate, but it is unable to keep it, without being the session or the authentication failing...

[SiNONiMiTY]

So it means that after getting redirected to your homepage, the session variable was set to null? Have you tried clearing the cache, route & views? Also try re-registering your classes in the autoloader.

php artisan view:clear
php artisan cache:clear
php artisan route:clear
php artisan optimize

If the above methods above did not help, maybe you'll have to wait for other developers that can help you with this. 🥇

[v-stein]

Yes, already tried all these.
Guess you're right that I'll have to wait a bit.

Thank you anyway.

[axelitus]

Your issue is strange. I just upgraded an application that uses authentication (and even with a custom UserProvider) and everything works fine with the auth middleware. My users can access all protected routes without problem.

My guess it has to do with the session if you say that somehow the User object is having a null value, maybe it cannot match the "active session" to a user.

What authentication guard driver are you using? (auth.php config file guards => web)

If you are using the SessionGuard have look at SessionGuard#L111. I would begin debugging over there.

Another thing that could be happening is that between the request and the middleware call, the user is being wiped out (by another middleware perhaps?)

[v-stein]

The authentication guard driver is 'session'.
So after looking at the file SessionGuard file as you recommended, that means that id is null (so session doesn't have "login") and the recaller is null too.

Edit:
I did call a die and dump of the session var ( dd(session()) ) and I figured out that the driver has the session name, the session id and the sha1 that it needs (format 'login_name_sha1') right after the login. If we manually go to a route (that requires the user to be authenticated) that also has a die and dump, we still have our session attributes as it should.
Only if we first login then redirect on a page without die and dump and that we try to dump these informations then, only the session id is left in the driver instance. Considerating the dump kills the execution of any code after, the session might be breaking after the request.

[axelitus]

Alright... so my guess with this new info is that somewhere in between the request and session load and the execution of the auth middleware, the session is being dropped (or the user is being logged out or something).

Can you remove the auth middleware from a secured route and dd(Auth::user());? It should have the currently logged in user. If not can you debug the Auth::user call? (It should go to the Session guard and through the user() function there). In the meantime let me debug my side and identify the line which sets the user.

Edit:
I've debugged my code and I found out that when a session exists, the user is set in SessionGuard.php#L132.
If your user is not being loaded then there must be something wrong with your session (you should check for timezone differences, permissions, etc.). The auth middleware calls the SessionGuard::check() (defined in the GuardHelpers trait) which in turn calls the SessionGuard::user() function to determined if there's a current user or not.
The function is called many times in one request, so if the user is set in one call but then it "disappears" then somewhere in your code the user is being dropped or logged out between calls as said before (the odd thing is that it works for 5.3). I'm inclined to believe is more a session issue...

[v-stein]

Alright, we did find the problem.
The source wasn't the session as we were focusing on, but that was indeed a middleware that was causing that all.

It was the api middleware group (that had AddQueuedCookiesToResponse, StartSession and ShareErrorsFromSession middlewares, with throttle:60,1 and bindings.
First thing we did that fixed the problem is we copied every middleware from the web middleware group (except VerifyCSRFToken).
When we saw that it was working, we removed the middlewares all by one and noticed the problem.

It seems that the middleware missing was EncryptCookies, even though that the encryption in the session configuration file was set to false... So the api routes were trying to get cookies it couldn't read because of encryption, and making the user fall back to login this way.

Thank you all for taking time to help with this issue that was particularly difficult to solve.

[webleyson]

This has been a thorn in my side. No upgrade. But I did a bit of work on a custom guard using a different machine. Hoping it may be something to do with permissions. Will run through these steps this evening!

[webleyson]

Hi. I’ve still not been able to solve my issue.
I’m not sure what I did but my local version just started working?!
No luck with my live site tho.
I’ve scrapped my project, pulled down fresh from git and it works locally but not the live server.
To resolve the issue locally I emptied my custom model and saved. Then re added it and that somehow worked.
How do you copy everything from the web middleware group?
I removed api routes from Auth config too. Same issue.

[bryanjamesmiller]

Thanks @v-stein I had the same issue and your provided solution worked for me.