I’m having trouble with users being impatient and requesting a new code to fast / very fast.
I’ve seen other sites having a timeout on how often a new code can be sent. Especially taking into consideration that requesting a new code invalidates the first sent.
I’ve have many users
logging in
request new code after 30 seconds
receiving first code
tryng to log in with the first (now invalid) code
complaining to me about what a crappy system I’ve setup
I already had to change the time-to-live of the codes, because a group of our users as standard had to wait for 8-10 minutes for getting the mail thru spam- virus- and other filters. Not good when the standard time-to-live-time is 3 minutes - But that hurdle has been solved.
Generally, sending and receiving email codes for login should not take that long. I have checked your tenant and noticed that you have a custom email provider configured.
In these situations, I recommend checking your tenant logs and your custom email provider’s email activity to verify whether the code is being sent.
Generally, on the Auth0 side, you should see logs indicating that the email was sent. This event indicates that Auth0 has deferred sending the email to your custom email provider. It does not actually mean that the code was sent from Auth0. From here, I suggest checking your custom email provider’s activity to see if the email was sent successfully, as Mailgun is solely responsible for sending emails.
We only use password-less for login, so it was a puzzle to find out, but the normal for that org is sadly 8-10 minutes - also for internal mail to the user at the neighbor desk.
But also gmail and hotmail sometimes has delays bigger that the users expect causing a “resend code” and the login-process hen easily breaks.
I already have a “please be patient”-notice where people choose how they want to login ( via google is also supported ), but people tend not to read it ;-/
It might be worth testing with the Auth0 built-in email provider and using the Try button on your email passwordless setting to see if the email is received on time.
I would also suggest creating a second dev-tenant for testing purposes. This way you do not interfere with any of the existing configurations on your current tenant.
The org just has a biiiiig delay i mail delivery. Nothing to do about it.
It takes up to a couple of second before the mail is delvered to their MX-server. Then up to 8-10 minutes before it’s in the users mailbox.
But that is just the extreme.
My aim with my feature-request is limiting the impatient users who are loggind in, don’t get their message within 15 seconds, and then ordering a new code invalidating the first.
