Hopping between passwordless and password login

Help
,
1

We started off with passwordless universal login (hosted page) and were met with a couple of OTP errors:
WE’RE SORRY. SOMETHING WENT WRONG

The logs simply stated this:

...
"details": {
  "body": {
    "connection": "email",
    "email": "martin@xxxxx.com",
    "auth0Client": "ey...fQ=="
  },
  "qs": {},
  "error": {
    "message": "undefined",
    "oauthError": "undefined",
    "type": "server_error",
    "uri": null
  }
},
...

Since there was no response from Auth0’s support and it kept happening in a live environment, we had to act fast (it’s a rather crucial product launch and auth failures like this aren’t something we can afford at this point).

We implemented password login instead, but now the existing members (who weren’t using Google’s OAuth)
could no longer log in nor could they request a new password via the password reset. The UI stated a success message that the reset e-mail was sent out, while the dashboard logged Failed Change Password Request - User does not exist.

At this point - what are our options? Should we revert to passwordless login with magic link (to avoid the OTP errors)? Is there a simple way to migrate all of the existing passwordless users to the password/database setup and have them generate themselves a new password?

Any (urgent/immediate) help appreciated!

2

That might just qualify as the most useless log message ever :no_mouth:. @auth0, y’all should really get on that. If that happened in my live environment, I’d start throwing with stuff.

Okay, on to trying to fix this situation:

This is actually true: as Auth0 treats all connections as separate databases, the user truly doesn’t exist in the username-password database. The way to fix that could be by exporting your existing passwordless users and importing them into the username-password database using the Import / Export extension.

I think this does sound like the best idea. I personally do prefer a magic link over a code, but that’s just me. However, you might run into the same issues again there too (as I believe a magic link is secretly a well hidden OTP).

So, how did you set up the passwordless lock page? Were you running Auth0 Lock Passwordless v11.2 or newer? Would it be possible to set the login page to the default Lock (passwordless) setting provided by Auth0 in the Hosted Pages section of the Dashboard?

3

I wanted to reach out to you @ajv and let you know that our support team is currently reviewing your open ticket and will reach out to once they have more information. Thank you for your patience.

4

@thijmen96 Thanks for the reply. So far auth0’s implementation hasn’t been exactly the breeze we’ve heard.

We figured that the user database was kept separate between connections, but weren’t aware of the extension :ok_hand:.

The magic link was actually what we initially tried to implement, but after a user failed to receive their magic link during a live demo, we had to hop back to using OTP-s simply for the demo to proceed and after that were a bit iffy to re-enable it. But I believe that was a mistake on my end or somehow not having configured magic link properly in our prod tenant.

The passwordless lock page is using Lock 11.9 with some custom CSS and translations, that’s about it.
I think the only config change besides the translations are these 2:

{
  auth: {
    // ...
    sso: false
  },
  passwordlessMethod: 'link',
  // ...
}

Atm the magic link seems to serve us well and hopefully our next step is to add the password option to complement the magic link, but that’s not something we wish to tackle atm.

Edit: Actually to our surprise there’s some errors with Magic link as well in our logs:

{
  "date": "2018-10-17T13:38:48.607Z",
  "type": "fp",
  "description": "Wrong email or verification code.",
  "connection": "email",
  "connection_id": "con_t...",
  "client_id": "SQ...",
  "client_name": "Qualitista",
  "ip": "74.xxx.xx.xxx",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36",
  "details": {
    "error": {
      "message": "Wrong email or verification code."
    }
  },
  "user_id": "email|5bc739...",
  "user_name": "jxxxn@axxxxxc.com",
  "strategy": "email",
  "strategy_type": "passwordless",
  "log_id": "90020..."
}
5

That error happens when the magic link is expired. I believe by default that happens after 5 minutes. You could consider extending that period to something like 15 minutes, that’s what we use in production and that usually works fine.

1 Like
6

I wanted to follow up and see if you had any additional questions at this time? I see from your support ticket that you were able to increase the magic link expiration time and work through any remaining challenges. Please let me know if there is anything else we can do to help, thanks!

7

Thank you for the follow-up, James. Everything seems to be much more stable now.
There’s just 2 things we’re trying to achieve now:

  1. is improve the login UX via the Lock - we’d like it if Lock could prefill the e-mail field for the passwordless login.
    Also for some reason rememberLastLogin does not seem to work (I know it can’t work for passwordless, but it should still remember the last Google login, correct?).

I found a similar issue here Hosted Passwordless with prefill of email address? and went through the source code for Lock. It looks like the prefill logic is there, but isn’t working for some reason?

  1. we can’t seem to properly configure the post-registration hook to fire (we’re aware that hooks are still in beta). We’ve configured the hook roughly based on the example rule (slack notification on sign-up):
module.exports = function (user, context, cb) {  
 const SLACK_HOOK = 'https://hooks.slack.com/services/###/#######'

 const slack = require('slack-notify')(SLACK_HOOK)
 const text = `:tada: New sign-up: ${user.username || user.email} (${user.email})`
 const channel = '#uustulnukad'

 slack.success({ text, channel })

 // return right away; Slack's API call will finish running in the rule's sandbox
 cb(null, user, context)
}

We’ve resorted to using Hooks instead of Rules because the example Rule for sign-up slack notifications didn’t contain context.stats in the login context, so we were getting notifications for every login (even auth renewals).

8

I’m glad to hear that everything is working out! Logouts can be tricky as there is three levels of logout as discussed here. Are you seeing an error when trying to use the post-registration hook? Also with the reference to context.status I’m including the documentation for all the properties that can be leveraged here.

10

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.