I am seeing the email connection across multiple auth0 accounts suddenly return a “We’re sorry, something went wrong when attempting to sign in” to Lock Passwordless.
The Chrome console is showing a couple of warnings and a CORB blocked file:
Failed to load https://buro9.eu.auth0.com/user/geoloc/country: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.lfgss.com' is therefore not allowed access.
VM763:1 Cross-Origin Read Blocking (CORB) blocked cross-origin response https://buro9.eu.auth0.com/user/geoloc/country with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.
(anonymous) @ VM763:1
getRequest @ lock-passwordless.min.js:9
init @ lock-passwordless.min.js:9
Reqwest @ lock-passwordless.min.js:9
reqwest @ lock-passwordless.min.js:9
a.getUserCountry @ lock-passwordless.min.js:14
f @ lock-passwordless.min.js:13
a @ lock-passwordless.min.js:13
auth0signin @ (index):1104
authSignin @ (index):1108
onclick @ (index):80
(index):1 Failed to load https://buro9.eu.auth0.com/passwordless/verify: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.lfgss.com' is therefore not allowed access.
But I do not believe that is the root cause.
The network tab shows that the start request worked fine and return JSON, but that the verify request returned text/plain and a body of OK.
Is this an update in the email connection that the old version of lock passwordless then fails on… a regression of sorts?
And if so, has lock finally been made passwordless friendly?
And is anyone else seeing this or knows how to resolve it?
Since you saw it break on multiple tenants simultaneously, I’m guessing this has something to do with the Legacy Lock API migration that’s currently taking place.
Thanks, I’ll advice the other customers affected by pointing them at this, and will migrate to using the later version of Lock that now supports Passwordless.
Many thanks for replying. I’d not received notification of a migration so was unaware.
I’m not 100% sure if the migration applies to this part of the login as well, but since it touches basically every other part of logging in, it wouldn’t surprise me. The deprecation of Lock Passwordless was indeed too silent, @auth0 could’ve done a bit of a better job there.
It does appear to solve it, support have got in touch and let me know that they’ve enabled the legacy lock api and I see it has fixed it on that tenant.
I’m letting the other customers that I know are affected also know.
First of all, apologies for this situation: as @thijmen96 mentioned this came in association with the Legacy Lock API flag so re-enabling it (which can be done by a tenant administrator during the grace period) will immediately address it.
We already identified the situation behind the two CORS issues you reported; for the first case with /user/geoloc/country this is an optional request so if you’re not using SMS Passwordless you don’t even need to worry about it and if you’re using SMS and the error triggers the end-user will still be able to login (Lock will just not show the country prefix according to the current IP).
For the second situation, this is indeed a blocking issue for the authentication so at this time you need to re-enable the flag; our expectations is that this issue with CORS on /verify will be addressed and in the future not have any impact even if the Legacy Lock API flag is disabled.