-
Notifications
You must be signed in to change notification settings - Fork 373
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: do call send sms hook when SMS autoconfirm is enabled #1562
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Test Coverage Report for Build 8906535523Details
💛 - Coveralls |
J0
changed the title
fix: don't call hook when SMS autoconfirm is enabled
fix: don't send an SMS when SMS autoconfirm is enabled
Apr 30, 2024
J0
changed the title
fix: don't send an SMS when SMS autoconfirm is enabled
fix: do not send an SMS when SMS autoconfirm is enabled
Apr 30, 2024
This reverts commit 1497e0e.
J0
changed the title
fix: do not send an SMS when SMS autoconfirm is enabled
fix: do call send sms hook when SMS autoconfirm is enabled
May 1, 2024
kangmingtay
approved these changes
May 1, 2024
Co-authored-by: Kang Ming <[email protected]>
hf
pushed a commit
that referenced
this pull request
May 3, 2024
## What kind of change does this PR introduce? Small quirk discovered while testing - it currently looks like when SMS Autoconfirm is set ``` GOTRUE_SMS_AUTOCONFIRM="true" ``` and an OTP request is made: ``` curl -X POST http://localhost:9999/otp -H "Content-Type: application/json" -d '{"phone": "<phone>"}' ``` an OTP is still sent. There's a substantial number projects (see internal for exact number) using this so probably will preserve this behaviour. This affects the edge case where `SMS_AUTOCONFIRM` is enabled but the Hook returns an error which may leave the developer puzzled since one might expect an SMS not to be sent with autoconfirm similar to `MAILER_AUTOCONFIRM` Before: - Enable Send SMS and autoconfirm, make a request with faulty URI - request should fail After: - Enable Send SMS and autoconfirm, make a request - message is sent as per current behaviour --------- Co-authored-by: Kang Ming <[email protected]>
hf
pushed a commit
that referenced
this pull request
May 6, 2024
🤖 I have created a release *beep* *boop* --- ## [2.151.0](v2.150.1...v2.151.0) (2024-05-06) ### Features * refactor one-time tokens for performance ([#1558](#1558)) ([d1cf8d9](d1cf8d9)) ### Bug Fixes * do call send sms hook when SMS autoconfirm is enabled ([#1562](#1562)) ([bfe4d98](bfe4d98)) * format test otps ([#1567](#1567)) ([434a59a](434a59a)) * log final writer error instead of handling ([#1564](#1564)) ([170bd66](170bd66)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
…1562) ## What kind of change does this PR introduce? Small quirk discovered while testing - it currently looks like when SMS Autoconfirm is set ``` GOTRUE_SMS_AUTOCONFIRM="true" ``` and an OTP request is made: ``` curl -X POST http://localhost:9999/otp -H "Content-Type: application/json" -d '{"phone": "<phone>"}' ``` an OTP is still sent. There's a substantial number projects (see internal for exact number) using this so probably will preserve this behaviour. This affects the edge case where `SMS_AUTOCONFIRM` is enabled but the Hook returns an error which may leave the developer puzzled since one might expect an SMS not to be sent with autoconfirm similar to `MAILER_AUTOCONFIRM` Before: - Enable Send SMS and autoconfirm, make a request with faulty URI - request should fail After: - Enable Send SMS and autoconfirm, make a request - message is sent as per current behaviour --------- Co-authored-by: Kang Ming <[email protected]>
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
🤖 I have created a release *beep* *boop* --- ## [2.151.0](supabase/auth@v2.150.1...v2.151.0) (2024-05-06) ### Features * refactor one-time tokens for performance ([supabase#1558](supabase#1558)) ([d1cf8d9](supabase@d1cf8d9)) ### Bug Fixes * do call send sms hook when SMS autoconfirm is enabled ([supabase#1562](supabase#1562)) ([bfe4d98](supabase@bfe4d98)) * format test otps ([supabase#1567](supabase#1567)) ([434a59a](supabase@434a59a)) * log final writer error instead of handling ([supabase#1564](supabase#1564)) ([170bd66](supabase@170bd66)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
…1562) ## What kind of change does this PR introduce? Small quirk discovered while testing - it currently looks like when SMS Autoconfirm is set ``` GOTRUE_SMS_AUTOCONFIRM="true" ``` and an OTP request is made: ``` curl -X POST http://localhost:9999/otp -H "Content-Type: application/json" -d '{"phone": "<phone>"}' ``` an OTP is still sent. There's a substantial number projects (see internal for exact number) using this so probably will preserve this behaviour. This affects the edge case where `SMS_AUTOCONFIRM` is enabled but the Hook returns an error which may leave the developer puzzled since one might expect an SMS not to be sent with autoconfirm similar to `MAILER_AUTOCONFIRM` Before: - Enable Send SMS and autoconfirm, make a request with faulty URI - request should fail After: - Enable Send SMS and autoconfirm, make a request - message is sent as per current behaviour --------- Co-authored-by: Kang Ming <[email protected]>
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
🤖 I have created a release *beep* *boop* --- ## [2.151.0](supabase/auth@v2.150.1...v2.151.0) (2024-05-06) ### Features * refactor one-time tokens for performance ([supabase#1558](supabase#1558)) ([d1cf8d9](supabase@d1cf8d9)) ### Bug Fixes * do call send sms hook when SMS autoconfirm is enabled ([supabase#1562](supabase#1562)) ([bfe4d98](supabase@bfe4d98)) * format test otps ([supabase#1567](supabase#1567)) ([434a59a](supabase@434a59a)) * log final writer error instead of handling ([supabase#1564](supabase#1564)) ([170bd66](supabase@170bd66)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Small quirk discovered while testing - it currently looks like when SMS Autoconfirm is set
and an OTP request is made:
an OTP is still sent. There's a substantial number projects (see internal for exact number) using this so probably will preserve this behaviour.
This affects the edge case where
SMS_AUTOCONFIRM
is enabled but the Hook returns an error which may leave the developer puzzled since one might expect an SMS not to be sent with autoconfirm similar toMAILER_AUTOCONFIRM
Before:
After: