This error just appeared this morning as far as I can tell, I think only in Safari. With new incognito window. Hosted login page uses custom interface with auth0.js v8. What is a verification page and why would its configuration fail?
1 Like
This usually happens when the Cross-Origin Verification Fallback isn’t configured properly for the client (under Advanced Settings → OAuth). Can you please provide more details about your setup? (In particular, the code you’re using) Were you testing Lock 11?
I was under the impression the fallback url wasn’t necessary when using the hosted login page? I’m not using lock. I’m using webAuth.redirect.loginWithCredentials() in auth0.js v8
I have the same problem. But I only get it when I try to log in via mobile devices.
Desktop browsers doesn’t seem to have this problem.
2 Likes
Same trouble here – seems to be iOS Safari in particular that’s having issues. Unlike the OP, I’m using embeded Lock v11, but the symptoms are identical. Setting a Cross-Origin Verification Fallbackas suggested in the other comment thread didn’t have any effect either.
1 Like
We’re having the same issue on iOS safari except we can reproduce it every now and then on desktop safari too.
We have the same problem, macOS Safari first time failed then successful login. iOS always have the issue. I can’t reproduce this in any other OS/browser.
Same issue. iOS Safari.
I found this article:
Specifically, that section of the docs, suggests that enabling custom domains would resolve this. The way I read that, switching to login.mycompany.com from mycompany.auth0.com would allow the origin to match, removing the need for Cross-Origin-Verification.
Enable Custom Domains and host your web application in a domain that has the same top level domain as the Auth0 custom domain. This way the cookies are no longer third-party and are not blocked by browsers.
For clarification, we are using the lock widget in staging and production. I’m a little confused about this statement on the Custom Domains Page:
If I use a custom domain, will I still be able to use my tenant.auth0.com domain to access Auth0?
Once you enable your custom domain in Auth0, you should be able to use either the default tenant.auth0.com or your custom domain. There are a few exceptions:
** If you are using embedded lock or an SDK, the configuration is pre-defined as using either your custom domain or the tenant.auth0.com domain, so you have to use one or the other.
I realize that once the lock widget is initiated with either tenant.auth0.com or my custom domain, we’d need to stick with one of the other, but I just want to confirm that if we enable Custom Domains, we can test that this is resolved by doing so in our Staging environment, while leaving Lock pointing at tenant.auth0.com in the meantime.
Can anybody confirm that for me?
Much appreciated!
John
Hey guys,
I’m noticing the same issue only on Safari, did you happen to find a solution?
J
We are also getting this issue, we have only noticed since we upgraded from lock.js 10.x.y to lock.js 11.3.1 a few weeks ago.
Only affecting safari users.
We also get this error message on safari users. I have opened a ticket with them. I’ll let you know when they come back with a solution
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