Warn users before destructive password reset

[AnthonyRonning]

Summary

• add a confirmation dialog before requesting password reset, warning that reset creates a new private key and deletes private encrypted data
• add delayed guidance on the reset-code form for users who may have signed in with Apple, Google, or GitHub instead of password login

Testing

• nix develop -c bun run --cwd frontend format:check
• pre-commit hook: bun build
• pre-commit hook: bun test

---

Summary by CodeRabbit

• New Features
  • Added a confirmation warning dialog before initiating password reset requests (Cancel/Continue; actions disabled while processing).
  • Added an informational guidance alert that appears after ~30 seconds if a reset code hasn't arrived, displayed above the Reset Code input.
  • Improved flow to preserve progress and transition users into the confirmation step; successful resets still redirect to the login page.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ba525474-3a72-4d94-9949-2efa87820fc6

📥 Commits

Reviewing files that changed from the base of the PR and between 639392f and 4f7ce9c.

⛔ Files ignored due to path filters (1)

• frontend/bun.lock is excluded by !**/*.lock

📒 Files selected for processing (1)

• frontend/package.json

✅ Files skipped from review due to trivial changes (1)

• frontend/package.json

---

📝 Walkthrough

Walkthrough

Two password reset components are updated: PasswordResetRequestForm adds an AlertDialog confirmation that gates reset initiation and moves reset logic into a new async helper; PasswordResetConfirmForm adds a 30s timer that shows an informational Alert when a reset code hasn't arrived.

Changes

Password Reset Flow Enhancement

Layer / File(s)	Summary
Reset request confirmation dialog frontend/src/components/PasswordResetRequestForm.tsx	AlertDialog-based warning gates reset requests. Submit now opens the warning dialog; requestPasswordReset handles trimming the email, generating & hashing a secret, calling os.requestPasswordReset, storing the secret, and switching to the confirm form with loading/error handling.
Reset code arrival guidance alert frontend/src/components/PasswordResetConfirmForm.tsx	Adds showCodeHelp state and a useEffect that sets it after 30s (unless code is entered or success is true). When enabled, an Alert with an Info icon, title, and description displays above the reset code input.
Dependency bump frontend/package.json	@opensecret/react dependency version updated from 3.1.1 to 3.2.0.

Sequence Diagram

sequenceDiagram
  participant RequestForm as PasswordResetRequestForm
  participant OS as os.requestPasswordReset
  participant ConfirmForm as PasswordResetConfirmForm
  RequestForm->>OS: requestPasswordReset(hashedSecret, email)
  OS-->>RequestForm: success / failure
  RequestForm->>ConfirmForm: showConfirmForm + secret

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~40 minutes

Possibly related PRs

• OpenSecretCloud/Maple#26: Related package version update for @opensecret/react.

Poem

🐰 A rabbit nudges the reset gate,
"Confirm first" — then patiently wait,
If codes take flight and do not show,
A friendly hint will help you know.
Soft warnings, guides — the flow is clear.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: adding a confirmation dialog to warn users before initiating a destructive password reset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch aead-password-reset-warning

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cloudflare-workers-and-pages]

Deploying maple with    Cloudflare Pages

Latest commit:	4f7ce9c
Status:	✅  Deploy successful!
Preview URL:	https://191ffa5b.maple-ca8.pages.dev
Branch Preview URL:	https://aead-password-reset-warning.maple-ca8.pages.dev

View logs

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

[AnthonyRonning]

What I’d still test, in priority order:

1. Existing migrated email/password user on dev: login, refresh, existing chat, new chat.
2. Existing migrated guest user: login with UUID/password, existing chat, new chat, password change.
3. Disposable email/password user: password change and confirm the app keeps working without manual re-login.
4. Disposable email/password reset: confirm warning UX, complete reset, old chats gone, new chat works.
5. Google OAuth and Apple OAuth, if dev callback setup allows it. GitHub is now covered.
6. Restart/failover smoke: bounce/restart steady-state dev serving and confirm existing email/password + GitHub OAuth still work.
7. Optional API-key smoke for non-storage completions only. Lower priority since we intentionally didn’t change API keys.

The highest-value remaining checks are guest, password reset/change on the deployed dev stack, and a restart/failover smoke.

[marksftw]

QA Testing Results — PR #568 (aead-password-reset-warning)

Tester: Mark

Environment: Dev (Cloudflare instance)

Date: 2026-06-13

1. Existing migrated email/password user — PASS
   Login, existing chats, new chats, and refresh/new tab all work correctly. One UI note: archived chats open in the sidebar instead of the right panel. Severity is lowest; needs to be checked in production to determine if it's a regression.
2. Existing migrated guest user — SKIPPED
   No pre-migration guest account (UUID + password) was available in dev to test with.
3. Disposable email/password: password change — PASS
   Password change completes successfully without logging the user out. Existing chat context is preserved, new chats work, and all data survives page refresh and new tab.
4. Disposable email/password: password reset — PASS
   The warning dialog ("Resetting your password deletes private data") appears correctly and explains data loss clearly. The "No code yet?" help alert appeared after waiting on the confirmation screen. Reset email arrived with a valid 8-character code. Password reset completed successfully. Login with the new password worked. Old chats and projects were completely gone (expected). New chats created after reset worked correctly and persisted across refresh and new tab.
5. Google / Apple OAuth — SKIPPED
   Dev instance is running on Cloudflare; tester does not have access to the Google Cloud Console to configure OAuth redirect URIs. The OAuth code itself was not changed in this PR, so regression risk is low.
6. Restart/failover smoke — SKIPPED
   Tester does not have access to restart the dev backend running on Cloudflare.
7. API-key smoke — SKIPPED
   Not tested in this session. Lower priority since API key logic was intentionally not changed in this PR.

Verdict: Core auth and encryption flows (Steps 1, 3, 4) all pass. The new password reset warning UX works as intended. Ready from a functional QA perspective on the tested flows.

I am unable to test 2, 5, and 6. For number 2, I didn't have an existing anon account from before the migration. For number 7, I will try running a separate proxy where I can swap out the backend URL and test API access in the dev instance.