I am just installing Auth0 in my existing Angular application. I had installed the auth0.spa.js package when I realized I need to complete another task before I began to implement it. I went to work on the other task, with no Auth0 code whatsoever inside my application (not even an import of the installed package).
My angular project will not build and provides me with the following errors:
That is just asp.net serving as a backend for my Angular app (so I see it’scommunication via the the dotnet client), it’s not actually involved in anything.
I did uninstall and reinstall and then implemented auth0 before I dug any further, but I still find it pretty bizzare that simply having an unused import statement importing that function was enough to call it.
I am encountering a different problem, but it’s probably appropriate to make a separate post for that after I give up on searching for a thread, as it seems like someone must have encountered this problem before (my entire Angular app is behind an authguard: the login process was the only portion that was exposed, and I am transitioning to universal login, so every callback URL will be behind the guard, and the guard re-directs the user back to login before it finishes validating the token and recognizing that the user is, in fact, authorized, because isAuthorized$ returns false until it’s done validating the token)
And indeed this solution: Angular 8 isAuthenticated race condition once again proves to be a superior and more flexible implementation than the Angular SPA Start guide, and you should strongly consider updating that guide to reflect the tweaks he makes here. This implementation both accomplishes what’s already handled well by your Angular guide (applications w/ both authenticated and publically-accessible portions) while also handling Angular applications with no public-facing content, which your guide does NOT do (it produces either a recursive login loop or requires 2-3 logins looped before allowing access, depending on the redirect scheme: for that poster, it was 2, because he had a static landing URI, whereas for me it looped infinitely (because I tried to support the user logging back into any route within the app).
I wish that you would allow wildcards when configuring allowable callback URLs.
The ngAfterViewInit method might have worked for him, but resetting the route as a callback to authentication ensures there’s no race condition between ViewInit and the authentication process - in my case, the location.replaceState approach triggers another recursive authorization loop, because the authorization process is not yet complete.
Thanks for checking out my solution! I have changed a few things since I last wrote that post and have corrected some of the things you have pointed out. =D