Hi, I’m migrating from lock 9 to 11 in an AngularJs app. We also switched over to using a custom domain. Things are generally working, except that I can no longer use the ‘Impersonate User’ feature from the Dashboard. It appears that two things are going awry:
I’m getting the “state does not match” error, even if I set a state value when I initialize lock and use the same value in the impersonation advanced settings. (Oddly, the value that is set in local storage by auth0 is not the value I added in the impersonation advanced settings.)
It also appears that the token contains the .auth0.com domain instead of the custom domain, leading to an error, “Issuer https://.auth0.com/ is not valid.”
How can we continue to use impersonation on lock 11 with a custom domain?
to the options when I initialize lock. I first got an error because __tenant: 'mytenant' is apparently also required in overrides?
Sadly, I’m now getting a generic WE'RE SORRY, SOMETHING WENT WRONG WHEN ATTEMPTING TO LOG IN message in the lock widget.
I tried using the custom domain and the tenant.auth0.com domain as __token_issuer:. Both resulted in the same error. Which is correct?
As a sidenote, I saw documentation of the overrides config in the custom domain documentation but didn’t think it applied because it didn’t appear in the Embedded Lock section. The documentation is a bit confusing in that regard.
Separate question: Do you have a sense of when the idpInitiatedLogin flag will be released?
I’d love to send you a more helpful error, if only I was getting one! I have listeners in place for both 'authorization_error' and 'unrecoverable_error' that should log the errors in the console, but nothing at all is showing up. When I add debuggers in the listeners, they never get triggered.
A new Lock version has been released which supports the flag mentioned earlier. In understand that this recent issue is more related to the issuer, however, given that you likely update to this can we troubleshoot the full situation in latest version.
Can you update to Lock 11.5.1 provide the full configuration used to instantiate Lock both on login pages and redirect pages (unless the config is exactly the same). In addition, provide an HAR file for the series of requests starting with the impersonation one that then lead to an error (you can redact sensitive information like opaque access tokens or signatures of JWT tokens).
Sure, I can do that. But before I do, I’d like to make sure that I’m configuring the overrides correctly. In the docs for custom domains, the example shows options like:
For what it’s worth, impersonation was apparently failing because the angularjs (1.x) library angular-lock.js was not passing the _enableIdPInitiatedLogin flag to webAuth.parseHash
I added this flag to my local copy of angular-lock.js and impersonation works, the diff is
35a36,38
var allowIdPInitiatedLogin = false;
if (this.options._enableIdPInitiatedLogin === true)
allowIdPInitiatedLogin = true;
Hey Sally. This was posted several months ago but I wanted to post this for anyone who was a bit confused about the overrides in their lock configuration.
overrides: {
__tenant: config.auth0Tenant, // Refers to that user's TENANT
__token_issuer: config.auth0Domain // Refers to that user\'s CUSTOM DOMAIN
}
If anyone would like to troubleshoot the config values, you can simply use a console.log(config) from the hosted login page, then attempt to log in and look at the developer console. Probably not the cleanest solution, but it gives you an idea of what the config values are. To my knowledge, Auth0 doesn’t document these values terribly well (but maybe I simply haven’t found that documentation).