running itself out of node_modules?

I am just installing Auth0 in my existing Angular application. I had installed the 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:

fail: Microsoft.AspNetCore.SpaServices[0]
      ERROR in node_modules/@auth0/auth0-spa-js/dist/typings/Auth0Client.d.ts:11:26 - error TS2304: Cannot find name 'Auth0ClientOptions'.

      11     constructor(options: Auth0ClientOptions);
      node_modules/@auth0/auth0-spa-js/dist/typings/Auth0Client.d.ts:28:33 - error TS2304: Cannot find name 'RedirectLoginOptions'.

      28     buildAuthorizeUrl(options?: RedirectLoginOptions): Promise<string>;
      node_modules/@auth0/auth0-spa-js/dist/typings/Auth0Client.d.ts:45:30 - error TS2304: Cannot find name 'PopupLoginOptions'. 

      45     loginWithPopup(options?: PopupLoginOptions, config?: PopupConfigOptions): Promise<void>;
      node_modules/@auth0/auth0-spa-js/dist/typings/Auth0Client.d.ts:45:58 - error TS2304: Cannot find name 'PopupConfigOptions'.

      45     loginWithPopup(options?: PopupLoginOptions, config?: PopupConfigOptions): Promise<void>;
      node_modules/@auth0/auth0-spa-js/dist/typings/Auth0Client.d.ts:56:23 - error TS2304: Cannot find name 'GetUserOptions'.

      56     getUser(options?: GetUserOptions): Promise<any>;
      node_modules/@auth0/auth0-spa-js/dist/typings/Auth0Client.d.ts:66:32 - error TS2304: Cannot find name 'getIdTokenClaimsOptions'.

      66     getIdTokenClaims(options?: getIdTokenClaimsOptions): Promise<IdToken>;
      node_modules/@auth0/auth0-spa-js/dist/typings/Auth0Client.d.ts:66:66 - error TS2304: Cannot find name 'IdToken'.

I cannot believe that your SDK is attempting to execute itself when I have not even implemented it into my application yet!

Hi @mikejunt,

Did you try to uninstall the package and reinstall it?

I can’t say I am familiar with Microsoft.AspNetCore.SpaServices, and wonder if that could have something to do with it.

Let me know,

That is just 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.

To add, the one ‘mistake’ he makes in this updated code is removing

authComplete$.subscribe(([user, loggedIn]) => {
    // Redirect to target route after callback processing

in favor of

  ngAfterViewInit(): void {

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.

Hey Mike,

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

Thanks and best of luck!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.