Ok. So after a few hours of debugging here is what I’ve discovered.
I have tried implementing the " Using the Authentication API with Auth0-PHP" solution. I first tried to mesh everything into our current auth0 login flow and some things are going a bit haywire.
I was able to get the example to work and redirect back to the “landing page” (the callback URL in the client) but I’m not sure how to access the user data since it is now stored in a sessionStore object. I have tried calling $session_store->get('user') to no avail. Also it appears when I check the cookies that the state parameter is still not showing up.
So I decided to try the example code as it is exactly in the documentation. I did have to change some variables around as I don’t have my getenv() configured correctly. Some guidance on getting that .env file located/setup would be much appreciated!
So I’m able to get to the auth-required.php page and it presents me with the loging view. Once I authenticate it appears the page hangs on *tenant name*/login/callback?code=blahblahblah
I feel like we are REALLLY close but the devils in the details. Any insight would be much appreciated!
Update:
I found under the “Local Storage” section of the Google Chrome Developer console that there are a number of Auth0 entries. A dump of one of these as a sample shows
1. {nonce: null, state: "-hGByn0wxYBCjPXgC3lCbiHQ2FNQR~rU", lastUsedConnection: "google-oauth2"}
1. lastUsedConnection: "google-oauth2"
2. nonce: null
3. state: "-hGByn0wxYBCjPXgC3lCbiHQ2FNQR~rU"
There is a state value stored here but it is not in the cookie for the site. Should it be in one place or the other? Is there a way to make this state value persist so my users don’t get kicked?
Also worth noting, our application utilizes custom PHP session names as a deterrent to CSRF. I’m wondering if the custom session names are causing an issue with the Auth0 handshake.