Skip to content
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

Auth fails to update user phone number under common conditions #1629

Closed
2 tasks done
iosephmagno opened this issue Jun 20, 2024 · 0 comments · Fixed by #1647
Closed
2 tasks done

Auth fails to update user phone number under common conditions #1629

iosephmagno opened this issue Jun 20, 2024 · 0 comments · Fixed by #1647
Labels
bug Something isn't working

Comments

@iosephmagno
Copy link

iosephmagno commented Jun 20, 2024

Bug report

  • I confirm this is a bug with Supabase, not with my own application.
  • I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

User phone is not updated correctly under some common conditions.

To reproduce bug, just update use phone number. We are using flutter plugin, but issue will occur with every plugin.

await Supabase.instance.client.auth.updateUser(UserAttributes(phone: phone));
final response = await auth.updateUser(UserAttributes(phone: phone));

As consequence of above code, Supabase sends an OTP code to verify the user request.
However, below issue occurs:

  • If user changes his number from numberA to numberB, and numberB was used recently or already used in the past, the OTP code is either not sent or it is sent but the verify will always fail.

To Reproduce

  1. Test with one user and two fixed phone numbers (numberA and numberB).
  2. Change user's phone number from numberA to numberB and soon after change back user phone number from numberB to numberA. OTP code won't be sent or verification will always fail.
  3. If numberB was already used in the past, OTP is not sent or verification fails. Sometimes this error can also be seen on console:
updating 65819238034: AuthRetryableFetchError

Expected behavior

  1. User should be able to change his/her phone number smoothly as long as the new phone number is not already assigned to another user inside project's Auth table.
  2. User should be able to change phone number from numberA to numberB and back from numberB to numberA. It can happen that user changes his mind soon after making his action and he must be able to reverse his action.

System information

├── supabase_flutter 2.5.6
│   ├── supabase 2.2.2
│   │   ├── functions_client 2.2.0
│   │   ├── gotrue 2.8.1
│   │   ├── postgrest 2.1.2
│   │   ├── realtime_client 2.1.0
│   │   ├── storage_client 2.0.2

CC: @dshukertjr

@iosephmagno iosephmagno added the bug Something isn't working label Jun 20, 2024
kangmingtay added a commit that referenced this issue Jul 4, 2024
## What kind of change does this PR introduce?
* Fixes #1629 
* Previously, rate limit errors were being returned as an internal
server error, which is incorrect. This PR checks for the underlying
error type returned and ensures that rate limit errors are surfaced
appropriately.

## What is the current behavior?

Please link any relevant issues here.

## What is the new behavior?

Feel free to include screenshots if it includes visual changes.

## Additional context

Add any other context or screenshots.
uxodb pushed a commit to uxodb/auth that referenced this issue Nov 13, 2024
## What kind of change does this PR introduce?
* Fixes supabase#1629 
* Previously, rate limit errors were being returned as an internal
server error, which is incorrect. This PR checks for the underlying
error type returned and ensures that rate limit errors are surfaced
appropriately.

## What is the current behavior?

Please link any relevant issues here.

## What is the new behavior?

Feel free to include screenshots if it includes visual changes.

## Additional context

Add any other context or screenshots.
LashaJini pushed a commit to LashaJini/auth that referenced this issue Nov 13, 2024
## What kind of change does this PR introduce?
* Fixes supabase#1629 
* Previously, rate limit errors were being returned as an internal
server error, which is incorrect. This PR checks for the underlying
error type returned and ensures that rate limit errors are surfaced
appropriately.

## What is the current behavior?

Please link any relevant issues here.

## What is the new behavior?

Feel free to include screenshots if it includes visual changes.

## Additional context

Add any other context or screenshots.
LashaJini pushed a commit to LashaJini/auth that referenced this issue Nov 15, 2024
## What kind of change does this PR introduce?
* Fixes supabase#1629 
* Previously, rate limit errors were being returned as an internal
server error, which is incorrect. This PR checks for the underlying
error type returned and ensures that rate limit errors are surfaced
appropriately.

## What is the current behavior?

Please link any relevant issues here.

## What is the new behavior?

Feel free to include screenshots if it includes visual changes.

## Additional context

Add any other context or screenshots.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant