I would be happy to take a look at this with you. When you get a chance can you please snag us a HAR file of the broken workflow and please be sure to select “Preserve log” to catch redirects and scrub the file of user passwords before sending it in a direct message along with your tenant name. Thanks!
I wanted to follow up @Jason.Humphrey and after further investigation I found similar state invalid issues where the WP application’s hosting provider had server-side caching enabled and as a result the Auth0 callback URL was cached, resulting in failed state validation in some cases.
Furthermore i will review the HAR file you sent over and see what I can find there. Thanks!
I’m using go daddy’s premium wordpress hosting services & I have already put a ticket in on there side and they said they have followed everything in the invalid state doc. They were unable to get it to work.
Hey @Jason.Humphrey, sorry for the trouble here. I took a look at the troubleshooting output you sent to Jim. It looks like the $_REQUEST global is missing both state and code there. Those are URL params that I see in the HAR but are not being added to $_REQUEST (PHP’s combined global for POST fields and GET params).
If you change the code from step 12 in the troubleshooting guide to:
If $_GET and $_REQUEST are different, something is messing with the globals for your install (the server or another plugin). If something IS doing that, I can add a fallback in the plugin on the next release (out in about a week or so). I can put together a patch in the meantime if we figure out that this is the issue.
Just for reference, here’s what the above output looks like in my test environment:
You can see the state and code parameters in there.
So, for this all to work, the $_REQUEST global need to be populated (normal, default Apache/PHP behavior) with what’s in the URL. We’re not doing anything out of the ordinary with the processing here, just grabbing what comes back in the URL. I’m not seeing any other redirects in the HAR file you submitted so I’m at a loss here.
The next things to check:
If you’re able to spin up a blank site with the plugin and the same configuration but a default theme and no other plugins, that would be a good thing to check.
If GoDaddy can review what we’re doing to see if there are any incompatibilities, we set a cookie and redirect here:
… and the do the verification here:
Both of the methods referenced there are in this class:
Again, nothing out of the ordinary going on here. If you want to connect me you GoDaddy support to try and hash this out, I’ll PM you my email address. We want the plugin to work in as many environments as possible so if there’s a change we can make, I’m happy to do it but nothing is popping out at me as something we’re able to change on our end.
It sounds like GoDaddy is handling these PHP globals in a non-standard way. If you still have a support thread going with them, can you add my email address there and point them to this thread? josh dot cunningham at auth0 dot com. We’d like to support as many of the big hosting providers as possible and if we need to augment the way we’re saving and retrieving this data, as long as it’s not a major change, we’re happy to do that.