Skip to content

fix: Phone Number Hint always returning "403 User denied consent"#121

Open
alaric505 wants to merge 1 commit intosurfstudio:mainfrom
alaric505:fix/phone-number-hint-consent-check
Open

fix: Phone Number Hint always returning "403 User denied consent"#121
alaric505 wants to merge 1 commit intosurfstudio:mainfrom
alaric505:fix/phone-number-hint-consent-check

Conversation

@alaric505
Copy link
Copy Markdown

Checklist

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Is there an existing issue for this PR?
  • Have the files been linted and formatted?
  • Have the docs been updated to match the changes in the PR?
  • Have the tests been updated to match the changes in the PR?
  • Attached videos/screenshots demonstrating the fix/feature.
  • Have you run the tests locally to confirm they pass?

Changes

What is the current behavior, and the steps to reproduce the issue?

When using getTelephoneHint to show the Phone Number Hint picker, selecting a phone number always returns a "403 User denied consent" error instead of the selected phone number.

This happens because the credentialPickerRequest handler in onActivityResult checks data.hasExtra(SmsRetriever.EXTRA_SMS_MESSAGE) before extracting the phone number. That extra is only present in the SMS User Consent flow and is never set in the Phone Number Hint flow, so the check always returns false and falls into the error branch.

What is the expected behavior?

Selecting a phone number from the hint picker should successfully return the phone number to the Flutter side via lastResult?.success(phoneNumber).

How does this PR fix the problem?

  • Removed the incorrect data.hasExtra(SmsRetriever.EXTRA_SMS_MESSAGE) guard from the credentialPickerRequest handler.
  • Directly calls Identity.getSignInClient(context).getPhoneNumberFromIntent(data) wrapped in a try/catch to handle extraction failures gracefully (returns a "500" error with the exception message).
  • Moved the "403 User denied consent" error to the outer else branch, where it correctly fires only when the user actually dismisses the picker (resultCode != RESULT_OK or data == null).

Tap on "Preview" ⤴

And choose one of the templates:

## Checklist

- [x] Have you added an explanation of what your changes do and why you'd like us to include them?
- [ ] Is there an existing issue for this PR?
- [x] Have the files been linted and formatted?
- [ ] Have the docs been updated to match the changes in the PR?
- [ ] Have the tests been updated to match the changes in the PR?
- [ ] Attached videos/screenshots demonstrating the fix/feature.
- [ ] Have you run the tests locally to confirm they pass?

## Changes

### What is the current behavior, and the steps to reproduce the issue?

When using `getTelephoneHint` to show the Phone Number Hint picker, selecting a phone number always returns a `"403 User denied consent"` error instead of the selected phone number.

This happens because the `credentialPickerRequest` handler in `onActivityResult` checks `data.hasExtra(SmsRetriever.EXTRA_SMS_MESSAGE)` before extracting the phone number. That extra is only present in the **SMS User Consent** flow and is never set in the **Phone Number Hint** flow, so the check always returns `false` and falls into the error branch.

### What is the expected behavior?

Selecting a phone number from the hint picker should successfully return the phone number to the Flutter side via `lastResult?.success(phoneNumber)`.

### How does this PR fix the problem?

- Removed the incorrect `data.hasExtra(SmsRetriever.EXTRA_SMS_MESSAGE)` guard from the `credentialPickerRequest` handler.
- Directly calls `Identity.getSignInClient(context).getPhoneNumberFromIntent(data)` wrapped in a `try/catch` to handle extraction failures gracefully (returns a `"500"` error with the exception message).
- Moved the `"403 User denied consent"` error to the outer `else` branch, where it correctly fires only when the user actually dismisses the picker (`resultCode != RESULT_OK` or `data == null`).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant