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.
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.
This is also happens to me with universal login on Safari when Prevent cross-site tracking
checkbox is checked
Resolved with enabling Use Auth0 instead of the IdP to do Single Sign On
in application configuration. Monosnap
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.
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.
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.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.