[ Solved - Help ] How to reset verify state? about remix-auth-totp

[andersr]

@dev-xo I think a 2-step route auth path would be preferable, as I think having separate routes would provide more flexibility.

Re. submitting a new login email, I think the the most recently submitted email should just overwrite what's currently in the session.

[dev-xo]

Yeah, already working on a fix for it.

This will be integrated directly into the Strategy, while keeping the client implementation unchanged.
If the provided form email is not the one that's already stored in session, the authentication flow should reset.

Will probably be ready today.
Thank you for the feedback @andersr!

[andersr]

Excellent , thanks!

[dev-xo]

v1.0.4 has been published @andersr.

Feel free to have a look, test it and tell me if everything works as expected.
In my dev environment it does.

Will require to add proper tests to it.

[dev-xo]

Hello @andersr! Good question actually.

I usually tend up to remove the cookie from the browser, but I think users should not do that, instead we should provide an easy way for them to enter another email, or simply reset the authentication flow.

Gonna look into it, and I will come up with an example for you.
Thanks for noticing @andersr!

P.S: Also, an advanced-usage.md file will be created inside the /docs folder. I have some advanced cases that could fit there.

[dev-xo]

Check the new Starter Example @andersr. It uses a 2-Step route verification.

If you go back to /login after inputed the first email, you could enter a different email or simlpy fix the typo from the first one.

On submit, database will invalidate previous OTP.

Notice me if this is what you was looking for @andersr.
Some new changes and advanced usages will be added soon.

P.S: Just added 3 new examples in case you wanna check them.

[andersr]

@dev-xo thanks for all the great insights and for updating the example to include a separate verify page. I tried running it and found that if I go back to the login page and submit a new email address, it does send another email, but to the original email rather than the new one.

[dev-xo]

Yeah, good point @andersr.

Noticed the OTP was correctly invalidated but didn't went deeper.
It has a lot of sense actually. We are probably re-sending the email that's already stored in session.

Ideally, I would want a client-side fix to avoid updating the Strategy.
Otherwise I should come up with a handler that could invalidate the Session on call.

Thanks for noticing! Will looking into it.

---

P.S: Also question for you @andersr.

• Do you prefer the 2-step route authentication path? (/login & /verify)
• Or for simplicity you would stick with a single one?

[andersr]

@dev-xo pulled the new version and tested it. Everything works as expected (email address updates on 2nd submit)

[dev-xo]

Happy to hear that @andersr. Thank you for the feedback!
Feel free to come up with more ideas / fixes. Them will be welcomed.