Auth0 Home Blog Docs

Invalid state (error 500) after PHP/SDK redirect

php

#1

Hey guys, having a sporadic problem for some of my users since switching to the PHP SDK. They’re getting a 500 server error immediately after redirect. I cannot seem to reproduce the error myself. When this happens, my nginx error log shows a similar entry as this thread describing a WP plugin problem. I’m not using Wordpress.

Looking through some suggestions on the thread above, I made the following changes to my setup:

  1. Added a version of my redirect page sans www.
  2. Added no cache headers to my redirect page.

I’ve not seen the error in my logs since making these two changes. Since this bug is intermittent I cannot reliably verify it’s been resolved for me. Going to keep an eye on the logs.

PHP message: PHP Fatal error: Uncaught Auth0\SDK\Exception\CoreException: Invalid state in /var/www/blah.com/vendor/auth0/auth0-php/src/Auth0.php:444

  • Which SDK does this apply to? (Ex: auth-node)
    auth0/auth0-php
  • Which verison of the SDK you are using? (Ex: 1.0)
    5.2.0 Auth0 PHP SDK.
  • Which version of the platform are you facing this error on? (Ex: Node 6.4)
    PHP 7.0.30-0ubuntu0.16.04.1
  • Was this code working before? Have you made any changes in the dashboard recently?
    Previously used lock javascript prior to the recent forced deprecation, worked perfectly then.
  • Please capture and attach the stacktrace, it helps a lot!

PHP message: PHP Fatal error: Uncaught Auth0\SDK\Exception\CoreException: Invalid state in /var/www/sonoclipshare.com/vendor/auth0/auth0-php/src/Auth0.php:444
Stack trace:
#0 /var/www/sonoclipshare.com/vendor/auth0/auth0-php/src/Auth0.php(371): Auth0\SDK\Auth0->exchange()
#1 /var/www/sonoclipshare.com/userverify.php(13): Auth0\SDK\Auth0->getUser()
#2 {main} thrown in /var/www/sonoclipshare.com/vendor/auth0/auth0-php/src/Auth0.php on line 444" while reading response header from upstream, client: 207.81.253.105, server: server_domain_or_ip, request: “GET /userverify.php?code=TN8UxPcr_WknzET9&state=5b6330f10d27e4.76039278 HTTP/1.0”, upstream: “fastcgi://unix:/run/php/php7.0-fpm.sock:”, host: “www.mydomain.com”, referrer: “https://accounts.google.ca/accounts/SetSID

  • Please share the code that is causing the error.
    No special code, using universal login.
  • Can you share a minimum reproducible?
    As the problem is intermittent, cannot do this.
  • Please capture and attach a HAR from the browser if this is an Authentication Bug / Issue.
    I’ll try to obtain one, but intermittent error makes this difficult.
  • If this is a Management API Client bug, some libraries allow you to capture a HAR.
    n/a

#2

Thanks Ben. I’m guessing that this solved your issue but let us know if not.


#3

Still getting this error, 10 times today. Any additional thoughts on tracking down the culprit @josh.cunningham?


#4

Your best bet is to look where that is verified and work backwards from there:

I would assume the URL parameter is working fine so I would probably start with checking into how sessions are working in your environment, maybe add some additional logging to catch more information about the error.

Something that just came to mind … can you visit your callback URL directly? And, if so, does it throw that same error if you leave off the necessary code and state parameters? Would there be any way that someone could get there, maybe even a bot?


#5

Good thought about the bot, but real users are getting the 500 error. Although the callback is publicly accessible, visiting it directly doesn’t throw the error. The callback just exits when it finds $auth0->getUser() is empty. Also, the callback userverify.php page isn’t an endpoint landing page for the user, it merely checks server credentials and some user data then redirects based on that info. This is where the 500 error gets thrown, so the user is stuck not logging in at all, breaking my web app.

I’m on board with expanding the logging of the error. For now I’m going to log the value of $state to see what it looks like:
throw new CoreException('Invalid state'.$state);
Any other suggestions on logging verbosity?


#6

The main things to figure out is … what is the incoming state in the URL (if any) and what the stored state is at that time. Should be clear which one is different or, more likely, empty.