"Unable to configure verification page" error on hosted login

We’re having the same issue as above with Safari Users.

Also, we’re getting a weird error when trying to use a verified Custom Domain. '“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”.

1 Like

To add to this, we rolled back the version of lock.js we were using to 10 from 11 on our dev environment and we are no longer experiencing this issue.

Auth0 have said they are depreciating this version at the end of the month, hopefully, it can be fixed by then.

We did the same. Rolled back to v10.

Also having the same issue after migrating to Lock 11. Please report back with any fix, thanks!

Versions prior to Lock 11 utilize endpoints that will no longer work after April 1:

/ssodata
/usernamepassword/login

If you’re using embedded Lock, upgrading to version 11 is necessary. Lock 11 uses different flows that essentially require custom domains in order for authentication to work across all browsers.

What do you mean by “Lock 11 essentially requires custom domains in order for authentication to work across all browsers.”

Custom Domains are not available in the Free Plans.

Are you saying that Free Plan users cannot use Lock 11?

Hi everyone. Let me clarify a few things:

  • Lock v11 is required is using embedded login (i.e. login on your application as opposed to login in Auth0’s hosted login page).
  • Cross-Origin Authentication is the new method Lock v11 uses when doing embedded login. If using the hosted login page, Lock v11 should work as before, no custom domain needed.
  • Custom domains is required to avoid third-party cookies issues when doing Cross-Origin authentication. Thus, if using embedded login, custom domain becomes almost a necessity.
  • The fallback verification page for cross-origin authentication solves a small subset of issues when it’s not possible to use custom domains. But since it’s not bulletproof, we recommend either using custom domains or moving to universal login (hosted login page).
  • The fallback verification page shouldn’t be needed if using universal login (hosted login page). There might be a problem in one of the involved components if this is not working in iOS Safari. I’ll have the team check.
1 Like

We just tried Lock v11 on a hosted login page with iOS and everything works as expected.
If you are using Auth0.js in the hosted login page, take a look at the default template and see if that works fine.
If you are using Lock v11 or Auth0.js v9 in an embedded scenario, Safari will most likely prevent third-party cookies, meaning that embedded login won’t work unless you use a custom domain that matches the domain of your application. I.e. if your app is app.acme.com, your Auth0 custom domain should be something like id.acme.com.

Hope that helps

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.

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

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.

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.

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

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…”?

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.

1 Like

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.

17 Likes

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

1 Like

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

3 Likes

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.

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.