Email connection "We're sorry, something went wrong when attempting to sign in"

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 No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '' is therefore not allowed access.
VM763:1 Cross-Origin Read Blocking (CORB) blocked cross-origin response with MIME type application/json. See 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 Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '' 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?

To be clear… this has been working without modification for a very long time and suddenly stopped working this morning.

Alright… that’s weird. It now works for the code given above, but continues to be broken on all other sites I run.

What’s happening auth0 ?

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.

A quick fix for now could be to toggle the Legacy Lock API migration in the advanced settings of your tenant.

As to the point of Passwordless Lock, that library has been deprecated. Lock v11.2 and up support Passwordless. You can check out the migration guide at

1 Like

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.

1 Like

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.