-
Notifications
You must be signed in to change notification settings - Fork 398
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
fix: send otp in email link #379
Conversation
6bf63b8
to
7d2a125
Compare
7d2a125
to
352d36b
Compare
a82ff9c
to
99c2375
Compare
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.
Looks fine to me. But let me sleep on it and read once more before approving
return time.Now().Before(expiresAt) && (actual == expected) | ||
} | ||
|
||
func isUrlVerification(params *VerifyParams) bool { |
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.
/nit Would be nice if we could check directly params.Type == URLVerification
instead of via exclusion (e.g. it is not (email or sms) so it is url)
That said, it is not a priority and would require a refactor. Probably not within a scope of this PR.
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.
Yeah i thought about that too but the type (signup vs recover) is tightly coupled to the ConfirmationToken
& RecoveryToken
fields, so it would be hard to tell whether the URL is a confirmation or recovery URL if we introduced a params.Type == URLVerification
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.
Looks great! Thanks for the PR :)
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 may have overlooked it, but do we have a test case for: valid token used in combination with the email address of a different user?
yeah i can add a test for that too, in this case, the verification should be rejected because the valid token doesn't belong to that user. |
🎉 This PR is included in version 2.5.8 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Hi guys and thank you for your work! Can you please provide some information about your plans to support email OTP in supabase-js client? @J0 |
This aligns the connection handling behaviour with the rest of the functions in `api/verify.go`. This looks like it might have been a leftover bug during refactoring in PR supabase#379.
This is awesome @kangmingtay. Now the OTP code sent looks like this:
Unfortunately that's too long to copy manually. Especially on mobile that doesn't add much benefit over redirects. Instead an example code should look like this:
That way, a user could type it manually from the email notification they receive, and not have to close the app. I'm not sure how much of a headache it is to implement this, but it's the standard on most other services. |
great job @kangmingtay Now if it was possible to replace it with just 6 digits like in two-factor authentication... 😄 |
ycjho-qjvns-nadyy-kcpbu Is not easy at all for a user to copy... |
@bicijay agreed, this was a missed opportunity @kiwicopple thoughts? |
@bicijay @vbylen we're working on a PR to shorten the email otp to [6-10] digits long, thanks for the feedback everyone! |
Is there any ongoing work on this @kangmingtay ?
|
Hey @kaaloo, The work by @kangmingtay to shorten the email otp to 6-10 digits has been merged. Do check out the Thanks! |
* fix: send otp in email links * fix: allow verifying otps from emails * add tests for email_change verification * fix: add env var to configure email link / token expiry * docs: update README * fix: verify phone & email before fetching user * add test for invalid email otp
…upabase#424) This aligns the connection handling behaviour with the rest of the functions in `api/verify.go`. This looks like it might have been a leftover bug during refactoring in PR supabase#379.
* fix: send otp in email links * fix: allow verifying otps from emails * add tests for email_change verification * fix: add env var to configure email link / token expiry * docs: update README * fix: verify phone & email before fetching user * add test for invalid email otp
…upabase#424) This aligns the connection handling behaviour with the rest of the functions in `api/verify.go`. This looks like it might have been a leftover bug during refactoring in PR supabase#379.
* fix: send otp in email links * fix: allow verifying otps from emails * add tests for email_change verification * fix: add env var to configure email link / token expiry * docs: update README * fix: verify phone & email before fetching user * add test for invalid email otp
…upabase#424) This aligns the connection handling behaviour with the rest of the functions in `api/verify.go`. This looks like it might have been a leftover bug during refactoring in PR supabase#379.
What kind of change does this PR introduce?
{{ .ConfirmationURL }}
from their email templates to prevent cases where email clients preview the URL thus resulting in the token being consumed. (addresses Email client previewing links expires confirmation/reset/invite tokens #368)API Additions / Changes
POST /verify
now accepts anemail
field which would be used together with the token to verify the user.type=email_change
andMAILER_SECURE_EMAIL_CHANGE_ENABLED=true
, the old email will be used for verifying both OTPs sent to the old and new email address.Implementation Details
signupVerify
,recoverVerify
,emailChangeVerify
andsmsVerify
into a new function calledverifyUserAndToken
verifyUserAndToken
does the following:To-Dos: