Can I ask a few questions about the Angular Login Examples, it is really not clear what exactly is happening or what the cycle of events needs to be given a particular situation
I have looked at the two examples I could find on the Auth0 site and the Auth0 community forum and they have slight differences
But in any case I have an Angular 8 SPA and I am not using routes, in other words everything happens at localhost:4200 and the components are manipulated at that URL to display different stuff where I need it to display on the page
So I tried to implement the Auth0 login Angular example and since my callback will be to localhost:4200 I am calling localAuthSetup() from the auth service constructor
Since my top level appComponent will be the callback component I am calling
handleAuthCallback() from the onInit of appComponent.
But whether or not I call handleAuthCallback() from appComponent or from the constructor of auth service (as per the auth0 site example code) I see the following error under these circumstances:
I find that once I authenticate, the callback happens and the URL gets modified to something like
http://localhost:4200/?code=Y4l1xf-UFhrH8kJI&state=QWE2Wlp1TnVhVlZwWURtbmpLcUVEREZxYmZkb2lrZm1oWGdXR01vWmllMA%3D%3D#_=_
At which point my appComponent restarts and the localAuthSetup and handleAuthCallback methods both get called, and execute appropriately
But, If this is in my URL and I manually refresh the page, then I get this error in my console
core.js:5824 ERROR Error: Invalid state
at e. (auth0-spa-js.production.js:1)
at auth0-spa-js.production.js:1
at Object.next (auth0-spa-js.production.js:1)
at auth0-spa-js.production.js:1
at new ZoneAwarePromise (zone-evergreen.js:872)
at r (auth0-spa-js.production.js:1)
at e.handleRedirectCallback (auth0-spa-js.production.js:1)
at MergeMapSubscriber.project (identity-repository.service.ts:39)
at MergeMapSubscriber._tryNext (mergeMap.js:46)
at MergeMapSubscriber._next (mergeMap.js:36)
I see that the presence of the code and state URLParams drive some target URL decisions in the auth service code, but is it really a side-effect of the way this auth information is stored on the callback URL to mess up when a manual refresh of the browser is performed ?? Or have I just messed things up somehow?
The whole cyclical nature of the calls and when they execute and how they are all chained together in multiples when they do whateve they do is very difficult to understand.
Also when I first started testing this I could see two types of auth0 cookies in the browser, one for is authenticated and others that looked like one for each successful login, presumably with their embedded JWT ?
And now today all I see is the is authenticated cookie, nothing else
The relationship between the methods and the callbacks and the target URL’s and the app routing or lack of app routing and what will happen under what circumstances is pretty difficult to predict without any guiding documentation as to how all of these things interrelate.