signup: keep the typed username and email when the server rejects a submission #164

Öppen
öppnade 2026-08-02 12:30:27 +00:00 av supernaut · 0 kommentarer
Ägare

Why

Client-side validation cannot prevent the statuses the server decides: taken, ratelimited,
error, nomail. Each of them redirects to an empty form
(src/pages/api/signup.ts:67-73), so a user whose chosen username is taken retypes their email
address, re-picks the account type, re-accepts the terms — and solves a fresh proof-of-work,
because the token is single-use (src/lib/captcha.ts:179-181).

Options

  • Query string — rejected. It puts the email address into the URL, and from there into browser
    history, the edge access log, the log store and any Referer we emit. A data-minimisation
    regression for a convenience feature.
  • Short-lived draft cookie (proposed) — on the failing redirect set signup_draft
    (HttpOnly, Secure, SameSite=Lax, Path=/signup, Max-Age≈300) carrying username, email
    and account type; the page reads it, echoes the values and deletes it. Post/Redirect/Get is
    preserved and no personal data reaches a URL or a log line.
  • Drop the redirect and render from the POST — cleanest in theory, but /api/signup is a
    deliberate standalone endpoint and a non-redirect response reintroduces resubmit-on-refresh.

Needs a decision before implementation

Adding a cookie means editing both privacy policies: they currently say strictly necessary cookies
are used "for signing in and keeping your session secure"
(src/content/en/privacy.md, src/content/sv/privacy.md). Short-lived, user-initiated form state
is still strictly necessary and consent-exempt, but the policy should say so rather than be quietly
outgrown.

Notes

  • No password is ever collected on this form (credentials are set at the identity provider from the
    emailed link), so there is nothing secret to echo back.
  • Re-tick the terms checkbox only if the user actually ticked it — never pre-tick a consent control
    from a default.
  • The same gap exists on the re-issue form (src/pages/api/resend-setup-link.ts:34-40), one field.

Part of gitborg/gitborg-docs#69.

## Why Client-side validation cannot prevent the statuses the server decides: `taken`, `ratelimited`, `error`, `nomail`. Each of them redirects to an empty form (`src/pages/api/signup.ts:67-73`), so a user whose chosen username is taken retypes their email address, re-picks the account type, re-accepts the terms — and solves a fresh proof-of-work, because the token is single-use (`src/lib/captcha.ts:179-181`). ## Options - **Query string** — rejected. It puts the email address into the URL, and from there into browser history, the edge access log, the log store and any `Referer` we emit. A data-minimisation regression for a convenience feature. - **Short-lived draft cookie (proposed)** — on the failing redirect set `signup_draft` (`HttpOnly`, `Secure`, `SameSite=Lax`, `Path=/signup`, `Max-Age≈300`) carrying username, email and account type; the page reads it, echoes the values and deletes it. Post/Redirect/Get is preserved and no personal data reaches a URL or a log line. - **Drop the redirect and render from the POST** — cleanest in theory, but `/api/signup` is a deliberate standalone endpoint and a non-redirect response reintroduces resubmit-on-refresh. ## Needs a decision before implementation Adding a cookie means editing both privacy policies: they currently say strictly necessary cookies are used "for signing in and keeping your session secure" (`src/content/en/privacy.md`, `src/content/sv/privacy.md`). Short-lived, user-initiated form state is still strictly necessary and consent-exempt, but the policy should say so rather than be quietly outgrown. ## Notes - No password is ever collected on this form (credentials are set at the identity provider from the emailed link), so there is nothing secret to echo back. - Re-tick the terms checkbox only if the user actually ticked it — never pre-tick a consent control from a default. - The same gap exists on the re-issue form (`src/pages/api/resend-setup-link.ts:34-40`), one field. Part of gitborg/gitborg-docs#69.
supernaut lade till detta till projektet Bitborg Web 2026-08-02 12:34:29 +00:00
Logga in för att delta i denna konversation.
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Förfallodatumet är ogiltigt eller utanför gränserna. Använd formatet "åååå-mm-dd".

Inget förfallodatum satt.

Beroenden

Inga beroenden satta

Referens
bitborg/bitborg-web#164
Ingen beskrivning angiven.