-
-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Login with magic code #1818
base: master
Are you sure you want to change the base?
Login with magic code #1818
Conversation
We could also enable magic code for non-PWA users, imho it would be handy, token is 6-digits anyway and you can still click the link |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out I didn't submit this review two days ago 👀
I didn't test yet, only looked at the code. Left some questions.
We could also enable magic code for non-PWA users, imho it would be handy, token is 6-digits anyway and you can still click the link
I think this is the way to go. Less complexity in our code, less confusing for users and would allow to use emails on mobile to login on desktop and vice versa.
components/pull-to-refresh.js
Outdated
|
||
useEffect(checkPWA, []) | ||
useEffect(() => { | ||
typeof window !== 'undefined' && setIsPWA(checkPWA(window)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to check typeof window !== undefined
? Do effects not always run on the client?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I thought and still believe, I had to include typeof window !== undefined
because it seems that the code is being ran before client exposes window or on server while compiling. I might be saying some big bullshit here but that was the error I was getting.
function randomizeToken () { | ||
const words = bech32.toWords(Buffer.from(randomBytes(3))) | ||
return bech32.encode('token', words).slice(6, 12) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to think more if 24 bits is strong enough even if the link is only valid for 5 mins. Need to do some research how other services deal with the low entropy 🤔
Using bech32 encoding to go from random bytes to guaranteed alphanumeric characters is also an interesting choice. I think I know why you decided to use bech32 but can you elaborate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more a product of better safe than sorry
. Discussing with @huumn we agreed that bech32 encoding would produce a safer token than a standard 6-digit or even an 8-digit one.
The real reason is the resulting entropy, there are 32 possible characters per every 'digit', 32^6 = 1.073.741.824 (auto calc came in clutch lol).
24-bit or 32-bit entropy will result anyway in 32^6 after slicing!1
Edit:
go from random bytes to guaranteed alphanumeric characters
I realized I didn't address this, it's just one way to randomize the starting seed, we could choose whatever in place of that
Footnotes
-
if I'm not mistaken ↩
Redrafting to give this full priority to 'complete' the PR as everything else is ready for review |
Description
Partially fixes #727
Introduces a 6-character bech32 magic code (token) that expires in 5 minutes and can be used to login with email on PWA, especially iOS since atm there's no way to open a PWA from a link.
On
signIn
, the email and the callbackUrl will be temporarily saved on sessionStorageUpon submitting the magic code, it will build and redirect to a magic link (as we are used to) with the user inserted token and
email, callbackUrl
from sessionStorageAfter 3 failed attempts, a custom
useVerificationToken
will delete email and token from the database, requiring the user to get a new one.Screenshots
PWA
Web
email template:
error page:
Additional Context
afaik in this version of NextAuth we can't send parameters from signIn to /verify-request to /email without risking to be disruptive, thus I had to resort to sessionStorage
Also we can't send the default token AND the new custom token
Changed from 'login as [email protected]' to 'login with [email protected]' to make it independent from context (if login or setting an email); removed any reference to links
Checklist
Are your changes backwards compatible? Please answer below:
Yes, maintains the same behavior as before if on Web with the addition of the email via sessionStorage
On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
7: login, signup, link email, emails
7: token invalidation occurs on success and on 4th failed attempt
For frontend changes: Tested on mobile, light and dark mode? Please answer below:
Yes
Did you introduce any new environment variables? If so, call them out explicitly here:
No
Progress
pull-to-refresh.js
;email.js
)