Really? When I use the https version, it all works fine for me? The only time I was able to reproduce the error was when I started at the http version and Auth0 redirected me to the https version… I just checked again in another browser, https version was fine, http version was not.
Damn, this is a mind twister. This time it wasn’t because of https, but because of the www. So you start at https://stillproud.com and end at https://www.stillproud.com. So again, you’re not getting the same localStorage. The base URL you start and end the authentication at has to be identical. No difference in http/https or subdomains, or your auth will fail.
The way to solve it would be to have your web server force a redirect to one version, whether that’s with or without www is more of a marketing choice than a technical choice.
Certainly worth a try! I have to drive home now but will be online later to try it out.
Either way, thank you for your help!
Glad to help and good to know we’re in the same time zone 
I’ve been trying for the last hour or so but the same error pops up. I’m hoping my browser cache is causing the problem but I doubt it as I’ve cleared it a few times and tried incognito.
Would you mind trying on your side please?
https://github.com/DarryllRobinson/01-login_2
I tried a different way of setting up the variables as suggested here https://github.com/auth0/auth0.js/issues/777 and it worked!!
Basically, my callback code changed to callbackUrl: window.location.origin + '/callback'
I am having same error with one auth0 account but not with the other!
Callback urls are same for both account - any idea what could be the issue ?
The source file from the comment has been deleted. Any chance you can reproduce the file/order here?
Hi
What files do you need? I’ve pasted my callbackUrl variable below, if that helps:
callbackUrl: process.env.NODE_ENV === 'development' ? 'http://localhost:3000/callback' : 'https://stillproud.com/callback'
@chintandbhatt @PaulI @airmaster were you able to solve your issue?
I’m still getting the issue, however if I remove the error catching then I get a further call which is successful.
Looks initially to be an issue with the com.auth0.<state> cookies left behind
@PaulI is this the same as airmaster described in auth0js (what version?) returned by the parseHarsh function? or when do you see this error?
It is. We’re using lock widget v11.8.1 via the hosted pages and it seems to be a result of the parseHash function when hitting our callback page (React SPA).
It seems to hit the function twice (even although we’ve detected it hits our route once) and I’m not sure why/how.
I’ll try and get a simplified code sample together
2 Likes
Hey there @PaulI!
Have you managed to go through the obstacles you faced? Let me know if I need to dig into it and help you out!
Just in case this helps someone else out there. We solved our issue by updating connected-react-router in our React project. There was an issue with that component, which meant a route was getting rendered twice. This was causing 2 hits to the parseHash function. The first hit would pass, but the second would fail, however this would be reported first and the code would produce the error message for the invalid token first.
4 Likes
Glad you made it work!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.