mirror of
https://github.com/supabase/supabase.git
synced 2026-10-15 14:19:11 +03:00
Efekan
550f18b050
## Problem When users set up two-factor authentication (TOTP) in the dashboard, the enrollment modal asks them to name their authenticator app, with the placeholder suggesting `e.g.: Google Authenticator`. Many users keep or type this example name without realizing it is simply a custom nickname for the factor. On the sign-in MFA screen (`SignInMfaForm.tsx`), the code input previously rendered its label as: > `Code generated by Google Authenticator` This phrasing can lead users to believe that Supabase has locked their account specifically to Google's authenticator app—even when they actually scanned the QR code with Apple Passwords / iOS Keychain, 1Password, or Bitwarden. As reported in #51502, users who rely on their iPhone's built-in authenticator can get alarmed, thinking their authentication setup was unexpectedly swapped. Furthermore, if a user is genuinely locked out (e.g. lost device and backup codes), the "Email support" option previously only surfaced after an explicit authentication exception occurred, rather than being readily discoverable under the *"Unable to sign in?"* help section. Closes #51502 ## Solution 1. **Clear, standard form label & descriptive subtext**: - Replaced the ambiguous `Code generated by [Friendly Name]` label with a standard `Authentication code` label. - Moved the factor's friendly name into the field description: - When a name is configured: `From the authenticator app registered as [Friendly Name]` - Fallback when no name is set: `From the authenticator app registered to this account` - This makes it immediately obvious that `[Friendly Name]` is just the custom label they chose, rather than a hard vendor requirement. 2. **Direct support escape hatch**: - Added an **"Email support to regain access"** link directly into the *"Unable to sign in?"* list in both `SignInMfaForm` and `SignInRecoveryCodeForm`. - Users who are stuck now have an immediate, obvious way to reach out without needing to trigger errors or hunt down the support email. 3. **Extracted testable helper logic**: - Extracted friendly-name normalization and support mailto generation into a dedicated `SignInMfa.utils.ts` module. - Added unit test coverage in `SignInMfa.utils.test.ts` (9 tests covering trims, null/empty cases, and mailto parameters). ## Review instructions 1. Navigate to `/sign-in-mfa` (with an account that has a TOTP factor enrolled). 2. Verify that the input label reads `Authentication code`. 3. Check the subtext: verify that it clarifies `From the authenticator app registered as [Name]`. 4. Inspect the *"Unable to sign in?"* section at the bottom: - Confirm that "Email support to regain access" is visible and opens a pre-addressed email to `support@supabase.com` with subject `Unable to sign in via MFA`. 5. Check `/sign-in-recovery-code` and verify the same support link is present. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] Unit tests added and passing (`vitest run components/interfaces/SignIn/SignInMfa.utils.test.ts`) - [x] Code passes Prettier formatting check - [x] Code passes ESLint without adding warnings