"Unable to configure verification page" error on hosted login

[jaliperti1]

Yes, turns out my user had third-party cookies disabled. In my opinion, this renders Lock 11 pretty much useless for free account users. I will try to get the hosted login page flow to work for my app.

[jaliperti1]

Also, to clarify, my customer was using Google Chrome on Windows with Third-party cookies disabled in their settings.

[Abhishek_Hingnikar1]

As @nicolas_sabena mentioned, you’ll either need to use the hosted flow or setup custom domains, when using custom domains the cookie is treated as first party.

[nicolas_sabena]

Yes, turns out my user had third-party cookies disabled. In my opinion, this renders Lock 11 pretty much useless for free account users.

Not trying to sound smarty pants, and I understand your point, but just to clarify: it is the new (and far more secure) embedded login protocol (cross-origin authentication) that requires cross-domain cookies to establish an SSO session in the authorization server. Some browsers block third-party cookies (maybe more will do so in the future), and users can explicitly turn them off. So the only way for embedded login to work is to use the same domain in the app and in the authorization server (Auth0), hence custom domains.

[jaliperti1]

I appreciate the clarification. Quick question about custom domains:

I currently have apps in my account running on two separate root domains. (e.g., myapp.com and someotherapp.com). If I upgrade to a developer pro account is it possible for me to use custom domains for my login for both of these apps? Or no, since we are restricted to one root domain per tenant?

Since I can’t change the app’s domains at this point, I assume hosted login is the only way to go for me right now. Can you confirm? Thanks!

Joe

[manuel.reil]

Same here:

• Lock 11 in our Ember.js works for all browsers except Safari with 2 failed silent logins followed by 1 “Unable to configurre verification page” error in the Auth0 logs
• I set a custom domain and re-configured our app, then on showing Lock I get "You should not be hitting this endpoint. Make sure to use the code snippets shown in the tutorial or contact support@auth0.com for help” without being able to login (no browser works).

So, with approaching of the deadline next week, the fallback scenario for us is to lock out all of our Safari users, while moving to Lock 11 and not using custom domains.

Not so good. @andre.junior Have you found a solution for the “You should not be hitting this…”?

[andre.junior]

I was able to make it work by following the instructions by adding this:

    configurationBaseUrl: 'https://cdn.auth0.com',
    overrides: {
      __tenant: AUTH0_CUSTOM_DOMAIN,
      __token_issuer: AUTH0_DOMAIN
    }

As this modifications are required to make it work, I wish the API design for configuring Lock on this scenario was easier… adding an ‘overrides’ seems weird.

[catamphetamine]

I thought I’d chime in and express my disappointment in Auth0 here. You’re forcing users into the unknown (into the void) telling them “Just go for it” and when the few survivors come back injured you tell them “Well, whatever, didn’t you purchase our hazard suits? We’re not sure if they’re needed but you can try them as well”. That’s very unprofessional and clearly your team can’t handle it. You still have failed to admit in this thread that Lock doesn’t work without the paid “custom domains” feature (and is useless) and that your documenation is wrong deceiving people and luring them into a trap. Your level of user support is mediocre without anyone caring about this issue which is long-standing and resulting in direct income loss (mac-powered customers) for everyone except you.

[bortevik]

This is also happens to me with universal login on Safari when Prevent cross-site tracking checkbox is checked

[bortevik]

Resolved with enabling Use Auth0 instead of the IdP to do Single Sign On in application configuration. Monosnap

[rs6g10]

Hey’all, I’m having the same problem. I’ve tried everything from @bortevik’s recommendation to @andre.junior suggestion of using overrides. It definitely is a problem for us. Any other suggestion/recommendation would be helpful.

[waterdoo]

Running into this issue as well. I firmly believe the documentation should explicitly state that embedded login and custom domains only works if the user is coming from the same domain.

[dadapowell]

One thing I’ve learned: there does not seem to be a way to use a hosted login page with Lock Passwordless on a SPA (in my case, React) or Web App. The documentation only provides info on embedded login and custom UI, so custom domains are pretty much required for those use cases.

[dadapowell]

A quick update for anyone following this: I did manage to use a hosted login page with Lock Passwordless within my React app. I believe simply going to the Dashboard > Connections > Passwordless page and enabling the SMS option was what solved it for me. I didn’t make any other code changes (except switching from using the Lock widget – i.e. using the authorize() method [hosted] rather than the show() method [embedded]). Hope this is helpful and can save someone a few hours searching the documentation.