getTokenSilently throws Timeout error

[ilijapuaca]

Describe the problem

We are seeing a ton of timeout errors that happen shortly after page loads and getTokenSilently is invoked. Based on the logs, the error is thrown ~1-3 seconds after page loads, which doesn't match the implementation that I am looking at which supposedly throws this error (the only two places where I see this error being thrown is here and here).

#589 seems relevant, but it mentions #422 which seems to patch up an issue with event listener leaking, which likely isn't related?

What was the expected behavior?

Timeout errors not happening, or having them happen after a meaningful amount of time

Reproduction

Unfortunately I am not able to reproduce the issue consistently myself. We've had the issue occur 372 times to our users so far, so it is likely not a hard to reproduce edge case

Environment

• Version of auth0-spa-js used: 1.13.6
• Which browsers have you tested in? Chrome
• Which framework are you using, if applicable (Angular, React, etc): React
• Other modules/plugins/libraries that might be involved: N/A

[stevehobbsdev]

Thanks for raising @ilijapuaca - this is going to be really hard to provide help with without a reproducible sample that we can work with (we've tried before and couldn't get to the bottom of it as we never saw the issue).

Is there anything in the Auth0 Tenant Logs which might shed some light, or anything else you can tell us?

[ilijapuaca]

Hey @stevehobbsdev, unfortunately I don't have too much insight that I can provide which would allow for this to be easily reproduced. I did not find anything in the logs that I would relate to this issue.

One thing that comes to mind though, would this somehow happen if getTokenSilently was to be called multiple times in a short time period? I'm asking because there is a chance that happens in our case, where we try authenticating the user silently as early as possible, but also issue a few requests for which we try retrieving the access token using getTokenSilently.

Let me know if that could potentially explains the issue and I can try looking into it further, potentially providing some meaningful insight.

[stevehobbsdev]

One thing that comes to mind though, would this somehow happen if getTokenSilently was to be called multiple times in a short time period?

We have internal protection against that scenario; if you try to call multiple times in a short time span and we're still processing the same request, we'll give you the same promise back, so the call isn't actually made.

If you could look into this further and try to provide a reliable repro that would help us, then I would be happy to investigate. Closing this for now, but very happy to reopen and continue the conversation when you come back to us.

[nickroyerUBC]

We're getting a timeout error in getTokenSilently (that happens instantly) when using different versions of the auth0 spa js package. I tried to reproduce in one of the quickstarts however we weren't able to reproduce it in the simpler environment.

-- We load from the CDN:
https://cdn.auth0.com/js/auth0-spa-js/1.13/auth0-spa-js.production.js

1.12 & 1.12.1 -> Works exactly as expected

1.13 -> Has timeout error

1.13.1 -> 1.13.4 works exactly as expected

1.13.5 & 1.13.6 throws timeout error

1.14 still throws the error
I can test other versions as necessary

Due to external constraints this app is required to use promises instead of async / await

This is the relevant code: (NOTE: While testing I also tried to initialize via createAuth0Client however the same error occurred)

    const auth0 = new Auth0Client({
        domain: connector.IdentityConnector.Authority,
        client_id: connector.IdentityConnector.ClientId,
        redirect_uri: connector.IdentityConnector.RedirectUrl
    });
    if (auth0 === undefined)
        return false;

    hasAuth0 = true;
    connector.Auth0.App = auth0;

    connector.Auth0.App.getTokenSilently({}).then(function (token) {
        connector.Auth0.LoginHandler(token);
    }).catch(function (error) {
        if (error.error !== 'login_required') {
            console.error(error);
            //On error notify the identity service
            processLogin(connector, undefined, undefined);
        }
    });

Auth0Service.js:88 Error: Timeout
at n [as constructor] (errors.ts:3)
at new n (errors.ts:34)
at e. (Auth0Client.ts:691)
at tslib.es6.js:99
at Object.next (tslib.es6.js:80)
at c (tslib.es6.js:70)

[AndrewRayCode]

I too am getting an instant Timeout error from Auth0.

This is hard to trace because it's coming from some (polyfilled?) generator / step code in Auth0's source code.

[AndrewRayCode]

I'm not sure which, if any, of these resolved the issue, I did all of them:

1. When calling getTokenSilently Auth0 embeds an iFrame into the page that does a postMessage to the parent. This iFrame was getting blocked because my parent page didn't include the iFrame domain in the CSP. I added it there.
2. I was in incognito mode. Chrome blocks 3rd party cookies in incognito mode. To remove this, click on the eye on the right of the URL bar -> "Still not working?" -> "Allow 3rd party cookies"
3. My app's URL (localhost:port, in my case) wasn't listed in the Auth0 tenant's allowed callback URLs. I added it there.

I'm not sure which of the above helped resolve the issue. The error probably isn't a timeout, rather an unexpected error handling of the auth flow getting blocked. It would be nice if Auth0 provided a more user friendly error message here

[frederikprijck]

Hey @AndrewRayCode,

Thanks for the info. I do want to call out that both 2 and 3 shouldn't result in a timeout but show an error that indicates what's going on.

Sounds like the iframe and CSP might be responsible for the timeout. When we get a timeout, there isn't generally anything we can do as we aren't getting any more information ourselves.

Thanks.

[6lick]

Hi- I am seeing same timeout behavior with react app chrome extension. @AndrewRayCode what did you add to the CSP? Can you share an example of your CSP? Thank you!

[yulafezmesi]

did you able to resolve this issue? @6lick

[WrRaThY]

same problem here

[co-odw]

I'm doing something a little special in my development environment, using mitmproxy. As @AndrewRayCode mentioned, you can inspect the iframe and see which domain it's posting the message to. In my case, auth0 was trying to post to the original domain not my proxied domain where the parent iframe was. I needed to update that domain by setting the redirect_uri to my proxy.