Laravel-PHP Custom user Handling Invalid State Exception

[acooke]

Hello,

I have recently implemented the quickstart PHP laravel login guide for webapps. I successfully implemented the guide for generic user handling, however my app requires some custom user handling. I followed the remaining steps for custom user handling in the guide, but now I appear to be getting an invalid state error that is thrown each time a user attempts a login. More specifically when the $service->getUser(); method is called from within the /auth0/login/src/controllers/Auth0Controller.php file (line 35).

I’ve read through some other blog posts regarding this. I have identified that the states are mismatched from the /authorize endpoint that is called at login, and the /callback endpoint afterwards. I have uploaded some screenshots of what I see after I attempt a login, and my developer tools console.

It should also be noted that I am re-using accounts that I have registered in my auth0 tenant, and simply deleting them when I want to try a fresh login. I saw somewhere that may affect things? I have also been regularly clearing my browser cache on the browser I use to login, as well as clearing my PHP cache with the following commands:

1. php artisan config:clear
2. php artisan cache:clear

Any help is appreciated on this topic! Thank you.

Please include the following information in your post:

• Which SDK this is regarding: e.g. auth0-php

• SDK Version: e.g. 7.9.0

• Platform Version: e.g. PHP 7.4.3, Laravel 8.48.0

• Code Snippets/Error Messages/Supporting Details/Screenshots:
  

  
  
  
  

Is this a feature request or bug report? Bug?

[evansims]

Hey @acooke Welcome to the Community! Sorry you’re hitting trouble on this!

At first glance, I’m suspecting the invalid state appears to be related to those expiring state cookie notices in your console I’m seeing, but I’m not positive. I’m not sure why they’d be getting rejected as expired. That might just be how Firefox reports us purging them after verification, but it stands out. Let me see if I can duplicate this on my end.

Would it be possible to share the relevant portion of your code with me in a gist or repo so we can have a common baseline in our apps to work with?

Are you seeing this in browsers other than Firefox?

[acooke]

Hi Evan. Which part of the codebase do you consider relevant? I’m not sure how much (if any) I can expose, but some portions may be less sensitive than others.

I can confirm that this happens in Chrome as well.

[evansims]

Hey @acooke, I just ran a clean copy of the Laravel webapp quickstart, but I’m not able to reproduce this as it is. Here’s what I’m seeing: CleanShot 2021-06-23 at 16.18.54 · CleanShot Cloud

Note that the ?state param being different between some of those other endpoints is normal and fine. Those are different states, confusingly enough.

The reason this exception is being thrown is that: when the user visits your /login route, presumably you’re issuing a redirect using the SDK’s login() method. This method generates a ‘state’ nonce, and store’s it on the user’s device in a cookie. This is also forwarded to the /authorize endpoint for safe return to us later. Ultimately, after the authorization flow is complete and Auth0 redirects the user back to your /auth0/callback route, the originally generated state nonce is returned, and the SDK compares what is inside the user’s cookie and what was returned by Auth0. If they mismatch, or the cookie is missing, it throws an invalid state exception. You can see in your console screenshot that a ?state is being returned to /auth0/callback, and that should match a cookie present on the device, but those cookie warnings lead me to believe it’s just not getting stored properly there, so it’s failing.

I’m not seeing the cookie warnings in Firefox on my end, so it appears some sort of issue is occurring with the cookie storage along the way. Can you share what your app configuration looks like, aside from sensitive data like tokens?

Also, on your app’s /login route, can you use the Firefox developer tools’ Cookie panel within network requests to see what cookies are being set, and compare those with what is being returned to /auth0/callback as a state, and on that route, what cookies are being deleted? I can offer guidance there if you need further info

Which part of the codebase do you consider relevant?

Which part of the codebase do you consider relevant?

Really anything relating to how you’re starting the login flow, and what’s happening when the user returns to your app, would be useful

[acooke]

Thanks for the detailed response and explanation Evan!

@evansims

Can you share what your app configuration looks like, aside from sensitive data like tokens?

Currently in Auth0, my app is configured as such:

• Regular web application
• Application Login URI: not set
• Allowed Callback URLs: http://localhost:8000/auth0/callback
• Allowed Logout URLs: http://localhost:8000/
• Allowed web origins: http://localhost/

Other than that it’s all defaults.

I’ve attached some pictures of the cookies on the app’s /login route and the /auth0/callback route. Looks like there’s no state cookie being set on the /auth0/callback` route.

Below are some pictures of the login flow and what happens when the user returns to the app. We’re essentially just directing the user at /login route when they click the login button. as pictured here:

As you can see this follows the \Auth\AuthIndexController@login method, which hasn’t been modified except for this line:

where we’re just pointing the user at our /home endpoint once they’ve been logged in. Where some processing occurs (checking user roles, and setting up the environment based on that). Nothing with the sessions/cookies.

If you’d like to see more of the code around how I’ve configured our Auth0 Setup within my PHP app please let me know.

I appreciate all your help. Thanks!

[evansims]

Thanks, @acooke! My pleasure, I hope we can figure out what’s going wrong here. Hmm alright, nothing standing out to me yet in terms of code or config, everything looking pretty standard.

For peeking at the cookie requests, could you try capturing this panel for me from the login and callback routes? This might help diagnose where things are going awry a bit.

[acooke]

Hi Evan. Agreed, I’m not sure exactly what could be happening here and I’m really confused as it seems to be a unique instance of this exception.

Thanks for the clarification.

Please see the below screenshots of the login route and the callback route respectively:

[evansims]

Thanks for the extra info there @acooke! Ah ha, I think I’ve spotted the issue! You seem to be requesting your /login route from 127.0.0.1, but your app is configured to return to localhost after authentication flow. These are different domains, and the cookie wouldn’t be shared between those. I was able to reproduce the invalid state exception when doing things that way, but that is to be expected, as the cookie shouldn’t be shared cross-domain. Try starting your login from localhost instead of 127.0.0.1 and see if it works

[acooke]

Hahaha wow… Good catch! Thank you so much for your help Evan, that seems to have fixed my problem! .

Sorry to bring up another issue, but I noticed that the upsertUser method isn’t being called when I have a successful sign up/login with a new user now…

The flow is as follows: I sign up successfully with a new user that is not in the Auth0 database, then I am redirected back to / note this is not what I have in my configuration, after a user logs in, they should be redirected to /home as described. So I click login again and then I am directed to the /home page but since no user was created, I get a Trying to get property 'name' of non-object. From what I read, the initial sign up/login of a new user should trigger the upsertUser method. However it doesn’t get called when I sign up for the first time, nor when I log in for the first time.

Do you have any tips here? Please let me know if I should open another thread for this topic. Thanks again!!!

[acooke]

Update: I have just changed my config\auth0.php class to show the following (as mentioned in this discussion post:

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

Now I appear to be getting a Can't initialize a new session while there is one active session already error. Which lines up with some other posts that I’ve seen where users create an account, and are redirected the / page, only to attempt a login again and be presented with that error. I noticed in the quick start guide it mentions that:

[I] should clear all cookies for the testing site and try again. This can happen when a session is set but an error occurs after or the process does not complete.

I’ve tried this, using incognito on both firefox and chrome, in addition to running the following commands on my server:

1. php artisan config:clear
2. php artisan cache:clear
3. composer dump-autoload
4. php artisan view:clear
5. php artisan route:clear

I’m still getting this error and behavior. Any ideas here? Thanks.

PS: I also noticed in the Auth0 logs that it’s recording these login and signup events as successful, but I’m still not seeing an indication that it’s hitting my upsertUser method.

[evansims]

Hey @acooke, that error is to be expected if there is an active session attached to the end-user device when a change is made to the backend session scheme. This is raised by the underlying PHP SDK when a user object is already present in the session, as can be seen here: auth0-PHP/Auth0.php at main · auth0/auth0-PHP · GitHub

Be sure to clear sessions on both the backend and the end-user device and that will be resolved. A session must be getting held onto somewhere on one end or the other of your stack for that error to be thrown. I don’t believe any of those commands actually clear out Laravel’s sessions, you may be able to find some guidance on that here Artisan command for clearing all session data in Laravel - Stack Overflow

As far as using the eloquent driver approach, unfortunately, I’m not sure I can be of much help there; I’ve only worked with the Auth0 recommended route and admittedly I’m not an expert on that side of things

[acooke]

Hi @evansims

Thanks for the suggestions.

I have just tried clearing the session on my server, and opening a chrome and firefox window in incognito. It appears that this does not change the behavior.

When I attempt to sign up, it successfully signs me up, but redirects me to the / page of my app, where I see the login button again. I notice that it does not create my user in the DB as the quickstart guide mentions that it should.

Once I click the login button again after signing up with a fresh user, then I get the same error message: Can't initialize a new session while there is one active session already.

Do you have any other ideas here? Thanks.

[acooke]

I’ve tried a few more things. Each time I try a new tactic I clear my cache, config, and session on the browser and the server. I even restart my apache server for PHP.

When I have the config\auth0.php set with:

'driver' => 'eloquent',
'model'  => App\User::class,

And I attempt a signup/login with a fresh user, I get the Can't initialize a new session while there is one active session already error.

When I have the config\auth0.php set with:

'driver' => 'auth0'

And I attempt a signup/login with a fresh user, I get the: Trying to get property 'name' of non-object. error.

In both cases, I noticed that after a “successful” signup, I’m redirected to the / page in my application, rather than the /home page as I would expect after a successful login. This leads me to believe it has something to do with the errors/user not being created.

Please let me know if you have any other advice or can connect me with someone that may. Thanks.