Lock: checkSession fails on sub routes.

[rgerstenberger]

Calling checkSession from sub-routes in a SPA throws a timeout error (below). The actual network request fails much earlier with a 403 Callback URL mismatch.. We can't add every possible url path to the callback urls list because they are routes like mydomain.com/users/1234.

We are using lock for single-sign-on and need to verify session when a user is linked to any page from other domains. Also, the timeout error should throw immediately when the 403 is returned without delay (and probably not be a timeout error).

Simplified sample code:

const lockOptions = {
  oidcConformant: true,
  allowShowPassword: true,
  usernameStyle: 'email',
  allowSignUp: false,
  allowForgotPassword: false,
  languageDictionary: {
    loginSubmitLabel: "Log In",
  }
};

var lock = new Auth0Lock(
      options.clientID,
      options.domain,
      lockOptions,
    );

lock.checkSession({}, function (err, authResult) {
  console.log(err, authResult);
});

Error response:

error: "timeout"
error_description: "Timeout during executing web_message communication"
isOperational: true

EDIT: Forgot important info 🤦‍♂️

• Lock 11.1.0
• MacOS 10.13.2
• Chrome 63.0.3239.132

[luisrudge]

Hi, this doesn't look like a bug in the SDK. Please reach out to our amazing support team at https://support.auth0.com so they can better assist you with your scenario. Also, did you try to add this to the allowed callback urls? https://*.mydomain.com?

[luisrudge]

We can't know when the iframe throws an error, that's why we have a timeout there.

[rgerstenberger]

Thanks @luisrudge, I managed to get it working by adding a valid redirectUri to the checkSession options.

lock.checkSession({ redirectUri: 'https://listed-url.com' }, function (err, authResult) {
  console.log(err, authResult);
});

That said, the checkSession call results in two calls to /authorize. The first one succeeds with the new hardcoded redirectUri but the second one fails with redirect_uri === current browser url.

I'm curious why there are two calls being made from the iframe. It's also possible there is a bug in my code causing the two calls but since they are from an iframe it's hard to track down the initiator.

Thanks for the info!

[luisrudge]

What version are you using? I just released a patch (11.1.1) with a fix for empty redirectUris. Does it help in any way?

As for the two checkSession calls, lock calls checkSession once to see if you have an active session on the server to show the "Last time you logged in with" screen. If you want to disable that, turn sso off:

var options = {
  auth: {
    sso: false
  }
}

[rgerstenberger]

Thanks for the quick responses!

I upgraded to 11.1.1 and that doesn't appear to fix the issue but the workaround of hardcoding redirectUri still works.

We need the SSO functionality to handle login across multiple SPAs/domains but that initial call on lock instantiation isn't necessary. Is there another way to avoid that?

[luisrudge]

There isn't. We do that call to check if you have an active session, actually, so I think it's covering what you're trying to do, right?

[rgerstenberger]

I need to grab the accessToken so I still have to make that call directly.

[luisrudge]

Right. Makes sense. I created an issue to stop calling checkSEssion on init if you have rememberLastLogin: false. https://github.com/auth0/lock/issues/1238

[xinghengwang]

hm.. I have the same problem, but the add the proposed solution of adding redirectUri doesn't seems to work for me.

I also have a SPA, I am using version of Auth0-lock 11.2.3, and Auth0-js version. 9.2.2

I set it to auto refreshToken every 10 min just to test this.

If I am on the base url: http://localhost:8080, the checkSession works fine to refresh the Token.

but I am on any other subroute http://localhost:8080/foobar/
Then it always times out with:

{ error: "timeout", error_description: "Timeout during executing web_message communication" }

Yes, I added http://localhost:8080 to allowed web origins.

Any help is appreciated.

[xinghengwang]

Aha, I figured out.

Basically if any Sub Route isn't whitelisted in the __Allowed Callback URLs__, then if you are on that Sub Route, the checkSession will fail.

The unfortunately thing is, __Allowed Callback URLs__ do not allow wildcards for url (but allows wildcard for domains). So if we have dynamic created sub routes, it is really frustrating.

However, the hacky walk around is: if I physically set the
lock.checkSession({ redirectUri: 'http://localhost:8080/app' }, ....)
Where localhost:8080/app is one of urls whitelisted in __Allowed Callback URLs__, even though on my I am on another subroute, say, localhost:8080/foobar, it would still work.

These are other issues:

1. Even though the warningg message that I get is:
   There was an error fetching the SSO data. This could simply mean that there was a problem with the network. But, if a "Origin" error has been logged before this warning, please add http://localhost:8080 to the "Allowed Web Origins" list in the Auth0 dashboard:
2. The Allowed Web Origins is only for Domain Host not for full url paths.

Is this issue caused by the fact if no redirectUri is specificied, the redirectUri is always the current location URL, and if the current location URL isn't in the whitelisted callback URL, then it always fails? Is that case, this definitely is a bug, even if there is work around for now.

[luisrudge]

@xinghengwang do you have the same issue if you use the checkSession method from auth0.js?

[snstrauss]

Thank you @rgerstenberger very much!
I was having the exact same problem,
and the {redirectUri: allowed_url} works great for me!