feat(accounts): optional customer accounts with an auth email hook by kris1027 · Pull Request #20 · kris1027/BeStore

kris1027 · 2026-10-15T14:36:06Z

What

Customers can now make an optional account: they enter an email, confirm it from a link, and then choose a password. Guest checkout stays the default. An account shows past orders (including earlier guest orders with the same email), keeps an address book that fills in checkout, and lets customers change their profile and password or delete the account. Every auth email, for customers and admins, is now sent by our own Send Email Hook route through the existing email transport.

Why

Implements spec 0012, customer accounts (feature 12, Slice 6 in the scope). It reuses the Supabase Auth user pool the admin panel already uses, so there is no new auth vendor and no migration. Sending auth emails from our code also fixes spec 0004's shared reset template problem: the app now picks the customer or admin wording. The options weighed are in rationale.md.

Changes

Sign up, sign in and passwords (src/features/account/, app/(store)/account/(auth)/)

Sign up asks for an email only and always shows the same "Check your email" screen. The Supabase call runs in after() with a random throwaway password, so neither the reply nor its timing reveals whether an account exists.
The confirm link only spends its token on a POST ("Continue"), so link scanners cannot use it up. /account/confirm sends Referrer-Policy: no-referrer and noindex (next.config.ts).
When a sign up token is spent, confirmEmail swaps in a fresh throwaway password and ends other sessions, so a password planted through the public Auth API never survives a confirm (fix from the review, 6146a05).
Set password after confirm or reset, sign in with a safe next, sign out, forgot password. Sign in errors never say which part was wrong.

Send Email Hook (app/api/auth/send-email/route.ts, src/lib/email/, emails/)

Verifies the Standard Webhooks signature (standardwebhooks package) before anything else, accepts only signup and recovery, and picks the admin template from the database (an admin_users row or an authenticator), never from redirect_to.
Three new React Email templates: confirm sign up, customer reset, admin reset. Resend gets a hashed idempotency key, never the token hash.
New mailpit transport so local dev, e2e and CI can read every email. supabase/templates/recovery.html is gone.

Account area (app/(store)/account/(area)/)

Order history (paid orders only, 20 per page, dates in the store timezone) and an order page. A missing, foreign, guest or pending order all give the same not found.
Address book: up to 10 addresses, a default, dedupe on save.
Settings: name and phone, change password (asks for the current one, ends other sessions), delete account (asks for the password, warns about open orders). Admin users are refused on change and delete.
Account setup (src/lib/customer/setup.ts) creates the customers row and links earlier guest orders with the same email. One advisory lock per customer guards setup, merge, addresses and deletion.

Cart and checkout

Sign in merges the guest cart into the account cart, capped by stock (src/lib/cart/merge.ts). A signed in add with no cookie cart lands in the account cart.
Signed in checkout: the email is the account email (read only), the form starts with the pending order's address or the default address, saved addresses can be picked, and "Save this address to my account" is on by default. A blank profile phone or name is filled from the order once.
The order's customer_name is the profile name, else the delivery full name.
/checkout/complete offers "Create an account to track this order" after a paid guest order.

Admin and shared code

/admin/orders and the order page show "Account" or "Guest".
The proxy now also covers /account/* and /checkout/* to refresh the session; catalog pages still never touch Supabase. Signed out visitors on account pages get a 307 to sign in.
Session, form error and auth error helpers moved from src/features/admin-auth/ to src/lib/ so both features can use them.

Config, CI and docs

supabase/config.toml: sign up and email confirmations on, /account/** redirect URLs, the Send Email Hook.
New env: SEND_EMAIL_HOOK_SECRET, MAILPIT_URL, and EMAIL_TRANSPORT=mailpit; SEND_EMAIL_HOOK_URI is read only by the Supabase CLI. CI and Playwright set them.
Spec 0012 with rationale and verify list, the review record, a new runbook customer-accounts.md, and the scope updated.

How to test / verify

pnpm test: schemas, password checks and errors, paths and next safety, proxy decisions, the hook (signature, types, template choice), the actions and log redaction.
pnpm test:db (needs pnpm db:start): account setup and order linking, orders, addresses, settings and deletion, sign up from an order, cart merge and signed in checkout.
pnpm test:e2e tests/e2e/account tests/e2e/admin/password-reset.spec.ts: every account flow plus the admin reset through the hook, with axe on every account page. Locally, set SEND_EMAIL_HOOK_URI to the port your dev server uses and restart the stack.
The manual pass is in verify.md. Four items there are still open: the leaked and reused password messages on set password, the Resend idempotency key format, setup using the user Supabase returned when the browser holds a stale cookie, and a tampered signUpFromOrder request.

Risk & rollout

No migration. The tables from spec 0002 carry the feature.
Auth emails now depend on the app. If the hook route or Resend is down, nobody can sign up or reset a password, admins included. Supabase's own mailer is no longer a fallback, and the failure shows only in logs.
Production setup is in the runbook and lands with deploy (feature 19): sign up and confirmations on in Supabase, /account/** redirect URLs, the hook URL and secret in Supabase and Vercel, and a Firewall rate limit on /account/* and /checkout/complete. Not deploying yet, so none of it is part of this PR.
Shared session: signing out on the storefront also signs an admin out of /admin in that browser.
Review (record): the major finding (planted password) is fixed. The minors are still open:
- A leftover cart cookie can let a signed out visitor on the same browser see and add to a customer's cart (hasLiveCart does not check ownership).
- A guest cart merged on sign in can leave its pending order's Stripe session open, so paying both gives two orders (accepted in spec 0012, Consequences).
- Set password accepts any customer session without the current password (the documented design).
- Account deletion holds a transaction open across the deleteUser call, capped at 15 seconds.
Other accepted tradeoffs (spec 0012, Consequences): paid orders keep their PII after deletion with no retention limit yet, and there is no email change or data export.