Compare commits
3 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Ben Stull
|
f7228d27f4 | ||
|
Ben Stull
|
de28272914 | ||
|
Ben Stull
|
55beba5c0a |
+458
-105
@@ -23,6 +23,464 @@ skip versions are the composition of each intervening adjacent
|
||||
release's steps in order — no A-to-B path is pre-computed beyond
|
||||
that.
|
||||
|
||||
## 0.14.0 — 2026-05-28
|
||||
|
||||
**Minor — no operator action required; new optional env var.** This
|
||||
release ships `DOCS.md` and the `/docs` route — a public-facing user
|
||||
guide that translates `SPEC.md` into plain prose for readers,
|
||||
proposers, and contributors. The originating need was the
|
||||
admin-vs-owner distinction on the `/admin/users` surface (the §6.1
|
||||
role separation was load-bearing but only documented in spec voice);
|
||||
the response was a single guide that covers the framework's user-
|
||||
facing surfaces end-to-end. Mirrors `/philosophy` end-to-end: a
|
||||
markdown file checked into the repo root, served by a sibling backend
|
||||
loader, rendered with `MarkdownPreview`. No schema migration. No
|
||||
required env-var changes. The new "Docs" header link sits alongside
|
||||
the persistent "About" link from §14.3 and is reachable by anonymous
|
||||
viewers per the same v0.3.0 anonymous-read contract.
|
||||
|
||||
### Added
|
||||
|
||||
- **`DOCS.md`** at the repo root — the user-facing guide. Covers
|
||||
reading anonymously, signing in, proposing an RFC, super-drafts vs
|
||||
active RFCs, the discussion-vs-contribution distinction (§10.10),
|
||||
working on a branch (contribute mode, AI proposals, manual edits,
|
||||
flags, branch visibility, contribute grants, hygiene), opening and
|
||||
reviewing PRs, graduation (§13), withdrawal and reopening, the AI
|
||||
participant (§6.6 / §6.7 / §18), notifications and watch states
|
||||
(§15), and the full roles-and-permissions story (§6 in plain
|
||||
prose: anonymous / contributor / admin / owner, per-RFC
|
||||
owners + arbiters, per-branch contribute grants, the write-mute,
|
||||
and the three structurally distinct "mutes"). Framework-neutral —
|
||||
no deployment-specific names or corpus references; consistent with
|
||||
`CLAUDE.md`'s separation-of-concerns rule.
|
||||
- **`backend/app/docs.py`** — sibling loader for `philosophy.py`.
|
||||
Reads `DOCS.md` from the repo root with the same disk-first,
|
||||
in-process-cached, `refresh()`-on-demand shape. Optional
|
||||
`DOCS_PATH` env var points at an alternative source (e.g. a
|
||||
meta-repo working-tree clone) for deployments that prefer that.
|
||||
- **`§17` endpoint** — `GET /api/docs` returns
|
||||
`{ "body": "<DOCS.md verbatim>" }`. Anonymous-reachable, same
|
||||
contract as `GET /api/philosophy`.
|
||||
- **`frontend/src/components/Docs.jsx`** — the `/docs` reading
|
||||
surface. Mirrors `Philosophy.jsx`: chrome with Back / "USER GUIDE" /
|
||||
Home affordances, body rendered through `MarkdownPreview`.
|
||||
|
||||
### Changed
|
||||
|
||||
- **`backend/app/api.py`** — imports `docs as docs_mod` alongside
|
||||
`philosophy` in the relative-import block; registers the new
|
||||
`GET /api/docs` handler immediately after `GET /api/philosophy`.
|
||||
- **`frontend/src/api.js`** — exports `getDocs()` alongside
|
||||
`getPhilosophy()`. Same fetch shape, different endpoint path.
|
||||
- **`frontend/src/App.jsx`** — imports `Docs` alongside `Philosophy`,
|
||||
registers the `/docs` route alongside `/philosophy`, adds the
|
||||
persistent "Docs" header link alongside "About", and adds the
|
||||
`DocsWithSidebar` chrome wrapper alongside `PhilosophyWithSidebar`.
|
||||
|
||||
### Upgrade steps (from 0.13.0)
|
||||
|
||||
- You **MUST** rebuild the frontend and restart the backend after
|
||||
upgrading so the new `/docs` route, the new endpoint, and the new
|
||||
loader are picked up. `frontend/package.json#version` and `VERSION`
|
||||
both move to `0.14.0`. No schema migration; the new endpoint
|
||||
serves a checked-in file.
|
||||
- You **MAY** set `DOCS_PATH` to an absolute path if your deployment
|
||||
hosts `DOCS.md` outside the framework's repo (e.g. as a sync target
|
||||
from a content repo). Unset is supported — the framework's
|
||||
`DOCS.md` at the repo root is the default, mirroring how
|
||||
`PHILOSOPHY_PATH` works for `/api/philosophy`.
|
||||
- You **MAY** customize `DOCS.md` for your deployment if you want
|
||||
deployment-specific phrasing layered on top of the framework's
|
||||
guide. The file is a regular markdown source; standard `vim`/`git`
|
||||
edits suffice. Framework upgrades that ship a new `DOCS.md` will
|
||||
show as a normal merge in your deployment-overlay layer.
|
||||
|
||||
## 0.13.0 — 2026-05-28
|
||||
|
||||
**Minor — schema migration required; new optional env vars.** This
|
||||
release ships the cookie / privacy consent surface (roadmap item #11,
|
||||
SPEC §14.5 / §14.6). Every viewer — authenticated and anonymous alike —
|
||||
now sees a non-modal bottom-of-page banner on first visit asking which
|
||||
categories of cookies they allow (essential / essential + analytics /
|
||||
essential + analytics + other). The choice persists in `localStorage`
|
||||
for anonymous viewers and in a new `cookie_consent` table for
|
||||
authenticated viewers, with server-side overriding local on sign-in.
|
||||
The framework also ships default `/privacy` and `/cookies` policy pages
|
||||
that deployments can layer their own policy URL on top of via two new
|
||||
optional env vars. No analytics SDK ships in this release — the
|
||||
consent infrastructure is wired so item #13 (v0.15.0) can read from
|
||||
`frontend/src/lib/consent.js` when the SDK lands.
|
||||
|
||||
### Added
|
||||
|
||||
- **Cookie consent banner** (`frontend/src/components/CookieConsentBanner.jsx`).
|
||||
Non-modal, bottom of viewport. Three single-select choices with
|
||||
inline descriptions. Visible until the user makes a choice; hides
|
||||
thereafter. Reachable for revision via the settings surface.
|
||||
- **Consent helper** (`frontend/src/lib/consent.js`). Exports
|
||||
`getConsent()`, `hasChosen()`, `onConsentChange(cb)`, `setConsent()`,
|
||||
`hydrateFromServer()`, `clearLocal()`. Cross-tab sync via the
|
||||
`storage` event. Item #13's analytics SDK reads consent here before
|
||||
importing.
|
||||
- **Privacy and cookies policy pages**
|
||||
(`frontend/src/pages/Privacy.jsx`, `frontend/src/pages/Cookies.jsx`).
|
||||
Default minimal policies that describe the framework's stance and
|
||||
list the cookies the framework sets. Deployments override via the
|
||||
two new env vars below; the framework's stub always renders above
|
||||
the link so the framework-level contract stays visible.
|
||||
- **"Privacy & cookies" tab** in `/settings/notifications` showing
|
||||
the current consent choice, the recorded-at stamp, and a "Change"
|
||||
button that re-opens the banner via a custom DOM event.
|
||||
- **`§17` endpoints** —
|
||||
- `GET /api/users/me/cookie-consent` — read the current consent
|
||||
record.
|
||||
- `PUT /api/users/me/cookie-consent` — write a new consent record.
|
||||
Upserts a single row per user, stamps `recorded_at` to now,
|
||||
accepts `essential` for symmetry but always persists it as true.
|
||||
- **Schema migration** `013_cookie_consent.sql` — new
|
||||
`cookie_consent` table keyed by `user_id`, three flags
|
||||
(`essential`, `analytics`, `other_cookies`), and `recorded_at`.
|
||||
(Renumbered from `012_*` during driver integration because v0.7.0
|
||||
also added a `012_otc.sql` migration that landed in the integration
|
||||
order before this one.)
|
||||
- **SPEC `§14.5` Cookie / privacy consent** — settles the banner
|
||||
shape, the three-category single-select, the storage shape (local
|
||||
for anon, server row for authenticated), the precedence rule on
|
||||
sign-in, and the `consent.js` helper surface for downstream
|
||||
callers including item #13.
|
||||
- **SPEC `§14.6` Privacy and cookies policy pages** — settles the
|
||||
`/privacy` and `/cookies` routes, the framework's stub content, and
|
||||
the `VITE_PRIVACY_POLICY_URL` / `VITE_COOKIES_POLICY_URL` override
|
||||
shape.
|
||||
- **SPEC `§5`** — names the `cookie_consent` table in the canonical
|
||||
app-tables list.
|
||||
- **SPEC `§17`** — lists the two new cookie-consent endpoints.
|
||||
- **SPEC `§19.2`** — surfaces four candidates: policy content via
|
||||
content-repo file vs env var, GPC / DNT headers, multi-language
|
||||
consent text, and the item #13 analytics-SDK gating dependency.
|
||||
|
||||
### Changed
|
||||
|
||||
- **`frontend/.env.example`** — documents the two new optional env
|
||||
vars `VITE_PRIVACY_POLICY_URL` and `VITE_COOKIES_POLICY_URL`. Unset
|
||||
is supported; defaults render the framework's stub.
|
||||
- **`backend/app/api_notifications.py`** — module docstring grew two
|
||||
endpoint lines; the new endpoints sit alongside the existing
|
||||
`/api/users/me/*` neighbors.
|
||||
- **`frontend/src/App.jsx`** — registers `/privacy` and `/cookies`
|
||||
routes (anonymous-reachable), wires `<CookieConsentBanner>` into
|
||||
the global chrome, and listens for a `rfc-app:cookie-consent-reopen`
|
||||
custom event to re-open the banner from the settings surface.
|
||||
|
||||
### Upgrade steps (from 0.7.0)
|
||||
|
||||
- You **MUST** rebuild the frontend and restart the backend after
|
||||
upgrading. `frontend/package.json#version` and `VERSION` both move
|
||||
to `0.13.0` and the build embeds the new env-var contract.
|
||||
- You **MUST** apply schema migration `013_cookie_consent.sql`. The
|
||||
migration creates a single new table keyed by `user_id` with three
|
||||
flag columns and a `recorded_at` stamp. The framework runs
|
||||
migrations automatically at process start; no manual step is
|
||||
required beyond restarting the backend so the migration runner
|
||||
picks the file up.
|
||||
- You **MAY** set `VITE_PRIVACY_POLICY_URL` to an http(s) URL that
|
||||
points at your deployment's full privacy policy. The framework's
|
||||
`/privacy` page renders its built-in stub above a link to the
|
||||
configured URL. Unset is supported — the stub is sufficient for a
|
||||
default-config deployment.
|
||||
- You **MAY** set `VITE_COOKIES_POLICY_URL` to an http(s) URL that
|
||||
points at your deployment's full cookies policy. Same shape as the
|
||||
privacy URL.
|
||||
- You **MAY** announce the new consent banner to your users. Existing
|
||||
authenticated users will see the banner on their next visit
|
||||
(because their `cookie_consent` row does not yet exist); their
|
||||
current sessions remain valid.
|
||||
|
||||
## 0.12.0 — 2026-05-28
|
||||
|
||||
**Minor — operator action required (new secret + new overlay).**
|
||||
CloudFlare Turnstile gates the email-entry step of the OTC sign-in
|
||||
flow against automated abuse (roadmap item #10, SPEC §6.2 / §19.2-
|
||||
settled). Since v0.7.0 made `/auth/otc/request` the primary human-
|
||||
auth path and v0.8.0 opened the request endpoint to any valid email,
|
||||
the OTC dispatch became the natural target for distributed scrapers
|
||||
fanning out to harvest "this email is admitted vs. this email is
|
||||
not" timing/bounce signals. The per-email cooldown stops the trivial
|
||||
back-to-back loop; the Turnstile challenge stops the distributed one
|
||||
by costing the attacker a browser-side proof-of-humanness on every
|
||||
request. The challenge runs before the bcrypt hash + SMTP send so a
|
||||
failed verify spends no rate budget and produces no envelope.
|
||||
|
||||
Scope: the widget renders on the email-entry step of `/login` only.
|
||||
The OTC verify step (where the user pastes the six-digit code) is
|
||||
already bottlenecked on email delivery and protected by the
|
||||
five-minute TTL + single-use consume on the row; a second challenge
|
||||
there would double the rate budget against the same abuse path
|
||||
without measurably more protection. If bots adapt to defeat the
|
||||
email-entry challenge specifically — pushing the abuse vector onto
|
||||
the verify step — a future release adds the second widget. The
|
||||
widget also renders on the passcode step's "Use a code instead"
|
||||
fallback dispatch since that route also calls `/auth/otc/request`.
|
||||
|
||||
Default policy: `TURNSTILE_REQUIRED=false`. The gate stays open when
|
||||
the secret is absent — the dev / test path, and the pre-rollout
|
||||
path while the operator is wiring the secret. Once the secret is in
|
||||
GCP Secret Manager and the site key is in the overlay, the operator
|
||||
**MAY** flip `TURNSTILE_REQUIRED=true` so a future config drift on
|
||||
the secret fails loudly (HTTP 500 "auth misconfigured") instead of
|
||||
silently disabling abuse defense.
|
||||
|
||||
No schema migration — Turnstile siteverify is stateless.
|
||||
|
||||
### Added
|
||||
|
||||
- **`backend/app/turnstile.py`** — the siteverify caller. POSTs
|
||||
`secret` + `response` (+ optional `remoteip`) to
|
||||
`https://challenges.cloudflare.com/turnstile/v0/siteverify` and
|
||||
returns a `VerifyOutcome` (`ok` boolean + `reason` enum:
|
||||
`ok` / `skipped` / `misconfigured` / `missing-token` / `failed` /
|
||||
`network`). Tunables read from env at call time so tests
|
||||
monkeypatch cleanly: `CLOUDFLARE_TURNSTILE_SECRET`,
|
||||
`TURNSTILE_REQUIRED`, and (test-only) `TURNSTILE_SITEVERIFY_URL`.
|
||||
- **`frontend/src/components/TurnstileWidget.jsx`** — the React
|
||||
wrapper around the official CloudFlare Turnstile JS API. Reads the
|
||||
site key from `import.meta.env.VITE_TURNSTILE_SITE_KEY`; renders
|
||||
nothing when the var is unset (the form still submits and the
|
||||
backend's `TURNSTILE_REQUIRED` policy decides admission). Loads
|
||||
the CloudFlare script once per page on first widget mount. Cleans
|
||||
up the widget instance on unmount via `turnstile.remove()` so a
|
||||
remount produces a fresh challenge rather than reusing a stale,
|
||||
already-consumed token.
|
||||
- **Backend tests** (`backend/tests/test_turnstile_vertical.py`) —
|
||||
five vertical scenarios: happy path (secret + valid token →
|
||||
admit), siteverify rejects → 400 + no envelope, missing-token →
|
||||
400 + no envelope, missing-secret-soft (default) → admit, and
|
||||
missing-secret-hard (`TURNSTILE_REQUIRED=true`) → 500
|
||||
"misconfigured". All five mock the siteverify HTTP call via
|
||||
`monkeypatch.setattr(turnstile.httpx, "post", …)`; no real
|
||||
CloudFlare keys are ever embedded.
|
||||
- **SPEC `§6.2`** — names the Turnstile gate on the OTC dispatch as
|
||||
the v0.12.0 settled shape; the §19.2 candidate from v0.7.0 closes.
|
||||
|
||||
### Changed
|
||||
|
||||
- **`backend/app/main.py`** — `OtcRequestBody` grows an optional
|
||||
`turnstile_token` field. The `/auth/otc/request` handler calls
|
||||
`turnstile.verify_token` first, before `otc.request_code`, so a
|
||||
failed challenge spends no rate budget and produces no envelope.
|
||||
The handler maps `misconfigured` → HTTP 500, all other failures
|
||||
(`missing-token`, `failed`, `network`) → uniform HTTP 400 so the
|
||||
response does not enumerate which leg of the challenge broke.
|
||||
- **`frontend/src/api.js`** — `requestOtc` accepts a second arg
|
||||
`{ turnstileToken }` and threads it into the request body. The
|
||||
positional signature stays backwards-compatible so calls that pass
|
||||
only an email still type-check.
|
||||
- **`frontend/src/components/Login.jsx`** — the email step and the
|
||||
passcode step both render `<TurnstileWidget>`. The submit button
|
||||
on the email step is disabled until the widget produces a token
|
||||
(when the widget is enabled at build time); the "Use a code
|
||||
instead" link on the passcode step has the same gate. A 400 from
|
||||
`/auth/otc/request` clears the token and surfaces a "couldn't
|
||||
verify you're human, please retry" status. The fallback-from-
|
||||
passcode path bounces back to the email step on 400 so the user
|
||||
gets a fresh challenge in the natural place.
|
||||
- **`backend/.env.example`** — documents `CLOUDFLARE_TURNSTILE_SECRET`
|
||||
and `TURNSTILE_REQUIRED` alongside the existing OTC tunables.
|
||||
- **`frontend/.env.example`** — documents `VITE_TURNSTILE_SITE_KEY`
|
||||
with the operator wire-up procedure (dash.cloudflare.com →
|
||||
Turnstile → Add site).
|
||||
|
||||
### Upgrade steps (from 0.10.0)
|
||||
|
||||
The operator **MUST** create a CloudFlare Turnstile site
|
||||
(dash.cloudflare.com → Turnstile → Add site, choose "Managed" widget
|
||||
mode), obtain the site key (public) and secret key (private), and:
|
||||
|
||||
- You **MUST** `flotilla secret set ohm-rfc-app CLOUDFLARE_TURNSTILE_SECRET`
|
||||
(paste the secret key when prompted) before the v0.12.0 deploy.
|
||||
The framework reads the secret at request time; deploying v0.12.0
|
||||
without the secret leaves the gate in its default soft-fail state
|
||||
(every request admitted regardless of token), which means abuse
|
||||
defense is silently off.
|
||||
- You **MUST** `flotilla overlay set ohm-rfc-app VITE_TURNSTILE_SITE_KEY <site-key>`
|
||||
so the frontend build embeds the site key and the widget renders
|
||||
on `/login`. The site key is public — it travels in the bundle and
|
||||
appears in every browser — so this is the overlay (non-secret)
|
||||
layer per the §3 invariant 1 split. Skipping this step leaves
|
||||
`/login` with no widget; even after the operator sets the secret,
|
||||
the backend would refuse every request as `missing-token` once
|
||||
`TURNSTILE_REQUIRED=true` flips.
|
||||
- You **MUST** rebuild the frontend and restart the backend after
|
||||
upgrading. `frontend/package.json#version` and `VERSION` both move
|
||||
to `0.12.0`. No schema migration; Turnstile siteverify is
|
||||
stateless. The site-key embed is build-time, so the rebuild after
|
||||
the `flotilla overlay set` is what actually wires the widget into
|
||||
the bundle the deploy serves.
|
||||
- You **MAY** `flotilla overlay set ohm-rfc-app TURNSTILE_REQUIRED true`
|
||||
once you've confirmed a real sign-in works end-to-end with the
|
||||
widget. The default (`false`) keeps the gate in soft-fail mode so
|
||||
a missing-secret regression admits requests rather than 500ing
|
||||
every sign-in attempt; flipping to `true` makes a future config
|
||||
drift on the secret fail loudly with HTTP 500 instead of silently
|
||||
disabling abuse defense. The framework's tested path is the
|
||||
flipped-to-true production shape; the default `false` exists for
|
||||
the dev / pre-rollout window only.
|
||||
- You **MAY** customize the Turnstile widget mode (Managed /
|
||||
Non-interactive / Invisible) from the dashboard at any time
|
||||
without redeploying — the site key stays the same, and the widget
|
||||
picks up the mode change on the next page load. The framework's
|
||||
tested path is "Managed" because it gives the operator a visible
|
||||
challenge surface to debug against.
|
||||
|
||||
If either of the two **MUST** secret/overlay steps is skipped, the
|
||||
deploy still boots and `/login` still serves; the failure mode is
|
||||
that abuse defense is off (default `TURNSTILE_REQUIRED=false`) or
|
||||
every sign-in attempt 500s (`TURNSTILE_REQUIRED=true` flipped while
|
||||
the secret is unset). The driver pauses the wave at the secret/
|
||||
overlay gesture so the operator confirms both are in place before
|
||||
the framework version pin moves.
|
||||
|
||||
## 0.10.0 — 2026-05-28
|
||||
|
||||
**Minor — schema migration required; new auth path is additive.**
|
||||
This release lands user-set passcodes after OTC (roadmap item #8,
|
||||
SPEC §6.2). After a successful one-time-code sign-in, the user can
|
||||
set a passcode (4–20 characters) and use email + passcode for
|
||||
subsequent sign-ins. OTC remains the structural fallback: a
|
||||
forgotten passcode is recovered by requesting a fresh code, and
|
||||
five consecutive failed passcode verifies lock the passcode path
|
||||
for 15 minutes (HTTP 423) while leaving the OTC path open. The
|
||||
`/login` surface now consults a new `GET /auth/passcode/check`
|
||||
endpoint after the email step to decide whether to render a
|
||||
passcode input or an OTC code input; an "Use a code instead" link
|
||||
on the passcode step lets the user fall back to OTC manually. The
|
||||
`/settings/notifications` page grew a new "Sign-in" tab where the
|
||||
user can set, change, or remove their passcode.
|
||||
|
||||
### Upgrade steps (from 0.8.0)
|
||||
|
||||
1. **MUST** restart the backend so migration `015_passcode.sql`
|
||||
runs. The migration adds four nullable columns to the `users`
|
||||
table: `passcode_hash`, `passcode_set_at`,
|
||||
`passcode_failed_attempts` (default 0), `passcode_locked_until`.
|
||||
Existing rows pass through with `passcode_hash = NULL`, which
|
||||
the runtime treats as "no passcode set" — every existing user
|
||||
continues to sign in via OTC unchanged, and can opt into a
|
||||
passcode from the new settings tab at any time.
|
||||
2. **MUST** rebuild the frontend so the v0.10.0 `/login` flow and
|
||||
the new settings tab ship. `frontend/package.json#version` and
|
||||
`VERSION` both move to `0.10.0`.
|
||||
3. **SHOULD** announce the new sign-in option to users. Wording
|
||||
suggestion: "You can now set a passcode for faster sign-in.
|
||||
We'll keep emailing one-time codes as a fallback — if you
|
||||
forget your passcode, just request a code as usual."
|
||||
4. **MAY** leave the §6.2 default lockout shape (5 attempts,
|
||||
15-minute window) unchanged. v0.10.0 does not expose env
|
||||
tunables for these; raising or lowering them lives in §19.2
|
||||
as a candidate.
|
||||
|
||||
### Added
|
||||
|
||||
- **`POST /auth/passcode/set`** — authenticated. Body `{passcode}`.
|
||||
Validates length (4–20) and refuses obvious patterns from a small
|
||||
denylist (`0000`, `1234`, `aaaa`, `password`, etc.). bcrypt-hashes
|
||||
the passcode and writes `users.passcode_hash` plus
|
||||
`users.passcode_set_at`. Clears any active lockout and the
|
||||
failure counter (a user setting a fresh passcode is implicitly
|
||||
re-authenticating). Replaces any prior passcode.
|
||||
- **`DELETE /auth/passcode`** — authenticated. Clears the passcode
|
||||
hash and the set-at stamp; the user is back to OTC-only.
|
||||
- **`POST /auth/passcode/verify`** — unauthenticated. Body
|
||||
`{email, passcode}`. Returns HTTP 200 + minimal user payload on
|
||||
success; HTTP 423 with `locked_until` when the account is in the
|
||||
lockout window; HTTP 400 for every other failure (the
|
||||
wrong-passcode and unknown-email modes both collapse to 400 so
|
||||
the response does not enumerate account state).
|
||||
- **`GET /auth/passcode/check`** — unauthenticated. Query param
|
||||
`email`. Returns `{has_passcode: boolean}`. The Login.jsx flow
|
||||
consults this after the email step to decide whether to render a
|
||||
passcode input or fall back to OTC. The response carries only
|
||||
the boolean; lockout state, the hash, and the `passcode_set_at`
|
||||
stamp are not leaked. An unknown email and a known-without-
|
||||
passcode email both return `false`, so the endpoint is
|
||||
account-enumeration-safe.
|
||||
- **Schema migration** `015_passcode.sql` — four ALTER TABLE ADD
|
||||
COLUMN statements on the `users` table:
|
||||
- `passcode_hash TEXT` (nullable) — the bcrypt hash. NULL means
|
||||
"no passcode set".
|
||||
- `passcode_set_at TEXT` (nullable) — ISO-8601 timestamp.
|
||||
- `passcode_failed_attempts INTEGER NOT NULL DEFAULT 0` —
|
||||
consecutive failure counter since last success.
|
||||
- `passcode_locked_until TEXT` (nullable) — lockout window
|
||||
expiry; verify refuses with HTTP 423 while populated and
|
||||
in the future.
|
||||
- **`backend/app/passcode.py`** — the passcode state machine:
|
||||
validation (length + denylist), bcrypt hashing, set/clear,
|
||||
status check, and the verify path with lockout management.
|
||||
- **`frontend/src/components/Login.jsx`** — extended to a five-step
|
||||
surface: email → passcode-or-code → optional post-OTC
|
||||
passcode-offer → optional set-passcode. The "Use a code instead"
|
||||
link on the passcode step re-dispatches an OTC and switches to
|
||||
the code step. A 423 from passcode verify auto-falls back to OTC
|
||||
with a visible status message.
|
||||
- **"Sign-in" tab** in `/settings/notifications` — shows
|
||||
passcode-set status, the recorded `passcode_set_at` stamp when
|
||||
set, and Set / Change / Remove buttons. Mirrors the §14.5
|
||||
"Privacy & cookies" tab pattern.
|
||||
- **SPEC `§6` / `§14.1` / `§17` / `§19.2`** corrections per §19.3
|
||||
rule 2:
|
||||
- §6 names the three current auth paths (OTC, passcode-with-OTC-
|
||||
fallback, OAuth-fallback-during-migration).
|
||||
- §14.1 documents the stepped `/login` surface and the passcode
|
||||
check endpoint.
|
||||
- §17 lists the four new `/auth/passcode/*` endpoints.
|
||||
- §19.2 surfaces four new candidates (passcode policy tunables
|
||||
via env, per-IP rate-limit on `/auth/passcode/verify`,
|
||||
passcode-change "old passcode" challenge, passkey/WebAuthn);
|
||||
the "device-trust 30d" entry's passcode cross-ref is updated;
|
||||
the "first-OTC profile capture" entry's roadmap cross-ref is
|
||||
updated.
|
||||
|
||||
### Changed
|
||||
|
||||
- **`backend/app/main.py`** — registers the four new
|
||||
`/auth/passcode/*` routes on the existing oauth router, alongside
|
||||
the v0.7.0 `/auth/otc/*` routes.
|
||||
- **`backend/app/api.py`** — `/api/auth/me` payload now includes
|
||||
`has_passcode` (boolean) and `passcode_set_at` (string or null)
|
||||
so the settings surface can render the Set / Change / Remove
|
||||
affordances without a second round trip.
|
||||
- **`frontend/src/api.js`** — adds `checkPasscode`, `verifyPasscode`,
|
||||
`setPasscode`, `clearPasscode` helpers, neighboring the v0.7.0
|
||||
`requestOtc` / `verifyOtc` block.
|
||||
- **`frontend/src/components/NotificationSettings.jsx`** — adds the
|
||||
`SignInSection` component between `MutesSection` and
|
||||
`PrivacyCookiesSection`.
|
||||
|
||||
### Tests
|
||||
|
||||
- **`backend/tests/test_passcode_vertical.py`** — 17 new tests
|
||||
cover: set requires session; check returns false for unknown and
|
||||
for set-less users; check returns true after set without leaking
|
||||
other fields; happy-path OTC → set → verify roundtrip; wrong
|
||||
passcode increments the counter without locking; five consecutive
|
||||
failures lock with 423 and persist `passcode_locked_until`;
|
||||
lockout expires and the next attempt clears the counter; the OTC
|
||||
path is unaffected by passcode lockout; clear wipes the hash and
|
||||
set-at; setting a new passcode replaces the prior one and resets
|
||||
the lockout; `passcode_set_at` updates on every set; validation
|
||||
refuses too-short passcodes and denylist patterns; `/api/auth/me`
|
||||
carries `has_passcode` and `passcode_set_at` correctly.
|
||||
|
||||
### Environment variables
|
||||
|
||||
None new. The existing `SECRET_KEY` continues to sign session
|
||||
cookies; passcode hashing reuses the bcrypt dependency added in
|
||||
v0.7.0. The lockout shape (5 attempts, 15 minutes) and the length
|
||||
range (4–20) are hard-coded in `backend/app/passcode.py`. See
|
||||
§19.2 for the env-tunable candidate.
|
||||
|
||||
## 0.8.0 — 2026-05-28
|
||||
|
||||
**Minor — schema migration required; admission semantics shift.**
|
||||
@@ -209,107 +667,6 @@ direct DB `UPDATE`.
|
||||
state is wired in the schema and the auth gate; v0.9.0 ships
|
||||
the admin UI that flips the column.
|
||||
|
||||
## 0.13.0 — 2026-05-28
|
||||
|
||||
**Minor — schema migration required; new optional env vars.** This
|
||||
release ships the cookie / privacy consent surface (roadmap item #11,
|
||||
SPEC §14.5 / §14.6). Every viewer — authenticated and anonymous alike —
|
||||
now sees a non-modal bottom-of-page banner on first visit asking which
|
||||
categories of cookies they allow (essential / essential + analytics /
|
||||
essential + analytics + other). The choice persists in `localStorage`
|
||||
for anonymous viewers and in a new `cookie_consent` table for
|
||||
authenticated viewers, with server-side overriding local on sign-in.
|
||||
The framework also ships default `/privacy` and `/cookies` policy pages
|
||||
that deployments can layer their own policy URL on top of via two new
|
||||
optional env vars. No analytics SDK ships in this release — the
|
||||
consent infrastructure is wired so item #13 (v0.15.0) can read from
|
||||
`frontend/src/lib/consent.js` when the SDK lands.
|
||||
|
||||
### Added
|
||||
|
||||
- **Cookie consent banner** (`frontend/src/components/CookieConsentBanner.jsx`).
|
||||
Non-modal, bottom of viewport. Three single-select choices with
|
||||
inline descriptions. Visible until the user makes a choice; hides
|
||||
thereafter. Reachable for revision via the settings surface.
|
||||
- **Consent helper** (`frontend/src/lib/consent.js`). Exports
|
||||
`getConsent()`, `hasChosen()`, `onConsentChange(cb)`, `setConsent()`,
|
||||
`hydrateFromServer()`, `clearLocal()`. Cross-tab sync via the
|
||||
`storage` event. Item #13's analytics SDK reads consent here before
|
||||
importing.
|
||||
- **Privacy and cookies policy pages**
|
||||
(`frontend/src/pages/Privacy.jsx`, `frontend/src/pages/Cookies.jsx`).
|
||||
Default minimal policies that describe the framework's stance and
|
||||
list the cookies the framework sets. Deployments override via the
|
||||
two new env vars below; the framework's stub always renders above
|
||||
the link so the framework-level contract stays visible.
|
||||
- **"Privacy & cookies" tab** in `/settings/notifications` showing
|
||||
the current consent choice, the recorded-at stamp, and a "Change"
|
||||
button that re-opens the banner via a custom DOM event.
|
||||
- **`§17` endpoints** —
|
||||
- `GET /api/users/me/cookie-consent` — read the current consent
|
||||
record.
|
||||
- `PUT /api/users/me/cookie-consent` — write a new consent record.
|
||||
Upserts a single row per user, stamps `recorded_at` to now,
|
||||
accepts `essential` for symmetry but always persists it as true.
|
||||
- **Schema migration** `013_cookie_consent.sql` — new
|
||||
`cookie_consent` table keyed by `user_id`, three flags
|
||||
(`essential`, `analytics`, `other_cookies`), and `recorded_at`.
|
||||
(Renumbered from `012_*` during driver integration because v0.7.0
|
||||
also added a `012_otc.sql` migration that landed in the integration
|
||||
order before this one.)
|
||||
- **SPEC `§14.5` Cookie / privacy consent** — settles the banner
|
||||
shape, the three-category single-select, the storage shape (local
|
||||
for anon, server row for authenticated), the precedence rule on
|
||||
sign-in, and the `consent.js` helper surface for downstream
|
||||
callers including item #13.
|
||||
- **SPEC `§14.6` Privacy and cookies policy pages** — settles the
|
||||
`/privacy` and `/cookies` routes, the framework's stub content, and
|
||||
the `VITE_PRIVACY_POLICY_URL` / `VITE_COOKIES_POLICY_URL` override
|
||||
shape.
|
||||
- **SPEC `§5`** — names the `cookie_consent` table in the canonical
|
||||
app-tables list.
|
||||
- **SPEC `§17`** — lists the two new cookie-consent endpoints.
|
||||
- **SPEC `§19.2`** — surfaces four candidates: policy content via
|
||||
content-repo file vs env var, GPC / DNT headers, multi-language
|
||||
consent text, and the item #13 analytics-SDK gating dependency.
|
||||
|
||||
### Changed
|
||||
|
||||
- **`frontend/.env.example`** — documents the two new optional env
|
||||
vars `VITE_PRIVACY_POLICY_URL` and `VITE_COOKIES_POLICY_URL`. Unset
|
||||
is supported; defaults render the framework's stub.
|
||||
- **`backend/app/api_notifications.py`** — module docstring grew two
|
||||
endpoint lines; the new endpoints sit alongside the existing
|
||||
`/api/users/me/*` neighbors.
|
||||
- **`frontend/src/App.jsx`** — registers `/privacy` and `/cookies`
|
||||
routes (anonymous-reachable), wires `<CookieConsentBanner>` into
|
||||
the global chrome, and listens for a `rfc-app:cookie-consent-reopen`
|
||||
custom event to re-open the banner from the settings surface.
|
||||
|
||||
### Upgrade steps (from 0.7.0)
|
||||
|
||||
- You **MUST** rebuild the frontend and restart the backend after
|
||||
upgrading. `frontend/package.json#version` and `VERSION` both move
|
||||
to `0.13.0` and the build embeds the new env-var contract.
|
||||
- You **MUST** apply schema migration `013_cookie_consent.sql`. The
|
||||
migration creates a single new table keyed by `user_id` with three
|
||||
flag columns and a `recorded_at` stamp. The framework runs
|
||||
migrations automatically at process start; no manual step is
|
||||
required beyond restarting the backend so the migration runner
|
||||
picks the file up.
|
||||
- You **MAY** set `VITE_PRIVACY_POLICY_URL` to an http(s) URL that
|
||||
points at your deployment's full privacy policy. The framework's
|
||||
`/privacy` page renders its built-in stub above a link to the
|
||||
configured URL. Unset is supported — the stub is sufficient for a
|
||||
default-config deployment.
|
||||
- You **MAY** set `VITE_COOKIES_POLICY_URL` to an http(s) URL that
|
||||
points at your deployment's full cookies policy. Same shape as the
|
||||
privacy URL.
|
||||
- You **MAY** announce the new consent banner to your users. Existing
|
||||
authenticated users will see the banner on their next visit
|
||||
(because their `cookie_consent` row does not yet exist); their
|
||||
current sessions remain valid.
|
||||
|
||||
## 0.7.0 — 2026-05-28
|
||||
|
||||
**Minor — schema migration required; new auth path is additive.**
|
||||
@@ -897,7 +1254,3 @@ names itself.
|
||||
- `CLAUDE.md` at the repo root capturing the separation-of-concerns
|
||||
rule for working sessions.
|
||||
|
||||
## 0.1.0 — v1 build
|
||||
|
||||
Initial release. See `docs/DEV.md` for the slicing plan and build
|
||||
history.
|
||||
|
||||
@@ -0,0 +1,605 @@
|
||||
# Using the RFC app
|
||||
|
||||
This is the user-facing guide to the Wiggleverse RFC framework — how to
|
||||
read what's here, propose a new RFC, contribute to one that already
|
||||
exists, and understand who is allowed to do what.
|
||||
|
||||
This guide describes the framework. Individual deployments brand and
|
||||
configure themselves independently — the name in the header and the
|
||||
corpus the RFCs are about belong to the deployment, not to this
|
||||
document.
|
||||
|
||||
For the *why* of the framework, read the [philosophy](/philosophy).
|
||||
For the binding technical contract, see `SPEC.md` in the repository.
|
||||
|
||||
---
|
||||
|
||||
## Reading without signing in
|
||||
|
||||
You can read the catalog and every public RFC without an account.
|
||||
Anonymous visitors can:
|
||||
|
||||
- Browse the catalog of super-drafts and active RFCs.
|
||||
- Open any RFC and read its canonical body.
|
||||
- Read any public branch — its diff and its chat thread.
|
||||
- Read any pull request — its diff, its conversation, its review
|
||||
comments.
|
||||
- Read the discussion that has accumulated on an RFC's main view.
|
||||
|
||||
Reading is open by design. The framework's claim is that the *argument
|
||||
behind a definition* is the evidence that the definition was earned,
|
||||
and an argument that disappears behind a sign-in wall stops carrying
|
||||
that evidence.
|
||||
|
||||
What you cannot do without an account: chat, propose a new RFC,
|
||||
create a branch, open a PR, drop a flag, or post on a discussion
|
||||
thread. Every write affordance is replaced with a sign-in prompt.
|
||||
|
||||
---
|
||||
|
||||
## Signing in
|
||||
|
||||
While the framework is in private beta, only invited email addresses
|
||||
can complete sign-in. If your email is on the allowlist, the
|
||||
"Sign in" button in the header completes the flow and lands you on
|
||||
the catalog with full read and write access. If your email is not on
|
||||
the allowlist, you'll be sent to a short "pending" page explaining
|
||||
the gate.
|
||||
|
||||
Once you have an account, you're a **contributor** by default — the
|
||||
role that grants every write affordance the app exposes, scoped by
|
||||
the per-RFC and per-branch rules described below.
|
||||
|
||||
---
|
||||
|
||||
## Proposing a new RFC
|
||||
|
||||
A new RFC begins as a proposal. The "+ Propose new RFC" button at
|
||||
the bottom of the catalog opens a small modal that collects four
|
||||
things:
|
||||
|
||||
- **Title.** The word, concept, or topic this RFC would define.
|
||||
- **Slug.** A kebab-cased identifier derived from the title. It is
|
||||
the entry's stable handle from this moment until it graduates;
|
||||
collisions with existing entries or open proposals are caught
|
||||
inline.
|
||||
- **Pitch.** One or two paragraphs answering *why this RFC is
|
||||
needed*. This becomes the body of the entry.
|
||||
- **Tags.** Optional. The AI suggests tags from the pitch; you can
|
||||
accept, dismiss, or type your own.
|
||||
|
||||
Submitting the modal does one concrete thing: it opens a pull
|
||||
request against the framework's meta repository, adding one new
|
||||
file under `rfcs/`. There is no other Git artifact and no other
|
||||
side-effect. You are returned to the **pending-idea view** for the
|
||||
new proposal.
|
||||
|
||||
A pending idea is publicly readable but not yet a super-draft. The
|
||||
catalog surfaces it in a "Pending ideas" disclosure at the bottom
|
||||
of the list. A conversation can accumulate on the pending-idea view
|
||||
before it is admitted — contributors can argue, in public, about
|
||||
whether the entry belongs in the catalog at all.
|
||||
|
||||
Three outcomes are possible:
|
||||
|
||||
- **Merge.** An admin or owner merges the proposal PR. The entry
|
||||
becomes a super-draft and graduates from the "Pending ideas"
|
||||
section into the main catalog. Any conversation that accumulated
|
||||
on the pending-idea view migrates with it.
|
||||
- **Decline.** An admin or owner declines, attaching a written
|
||||
comment. You see the comment on your next visit, along with a
|
||||
one-click affordance to revise and re-propose.
|
||||
- **Withdraw.** You can withdraw your own proposal at any time. The
|
||||
entry will not appear in any default view; the conversation that
|
||||
accumulated stays attached to the closed PR as historical record.
|
||||
|
||||
You are automatically the first owner of any RFC you propose. The
|
||||
claim flow described under [Roles & permissions](#roles--permissions)
|
||||
is for *other* contributors to add themselves as owners later, not
|
||||
for the proposer.
|
||||
|
||||
---
|
||||
|
||||
## What a super-draft is
|
||||
|
||||
A super-draft is an entry that has been admitted to the catalog but
|
||||
does not yet have its own dedicated repository. Most of the
|
||||
argument that shapes a definition happens here. The framework
|
||||
assumes — and the philosophy explicitly invites — that many
|
||||
super-drafts will not survive the argument, and that is fine. The
|
||||
entries that do survive earn their place in the catalog by being
|
||||
defensible in public.
|
||||
|
||||
Opening a super-draft from the catalog gives you the same surface
|
||||
an active RFC uses:
|
||||
|
||||
- The canonical body in the centre, read-only by default.
|
||||
- A chat thread on the right where the public conversation lives.
|
||||
- A breadcrumb dropdown listing any in-flight edit branches and
|
||||
any open body-edit PRs against this entry.
|
||||
- A "Start Contributing" affordance that cuts a fresh edit branch
|
||||
and lands you in contribute mode.
|
||||
|
||||
Edits to a super-draft body propagate through pull requests against
|
||||
the meta repository — there is no dedicated RFC repository yet.
|
||||
|
||||
---
|
||||
|
||||
## What an active RFC is
|
||||
|
||||
An active RFC is an entry that has been **graduated**. It has its
|
||||
own dedicated repository, an integer `RFC-NNNN` identifier, and a
|
||||
canonical body file (`RFC.md`) inside that repository. The catalog
|
||||
distinguishes super-drafts and active RFCs at a glance.
|
||||
|
||||
Opening an active RFC gives you:
|
||||
|
||||
- `main` — the canonical body, always read-only. Changes to `main`
|
||||
arrive exclusively through pull requests.
|
||||
- A breadcrumb listing every open branch and pull request on this
|
||||
RFC.
|
||||
- A per-branch chat thread on the right. Each branch has its own
|
||||
conversation, including `main` itself.
|
||||
- A "Start Contributing" affordance: on `main` it cuts a new branch
|
||||
and lands you on it in contribute mode; on any other branch you
|
||||
already have push access to, it flips that branch into
|
||||
contribute mode.
|
||||
|
||||
---
|
||||
|
||||
## Discussion vs contribution
|
||||
|
||||
The framework draws an explicit distinction between two surfaces
|
||||
that other tools tend to conflate:
|
||||
|
||||
- **Discussion** is what the RFC is *for*. The chat thread on an
|
||||
RFC's main view is the place for "what about this part?" or
|
||||
"have we considered…?" questions that don't yet warrant proposing
|
||||
a specific edit. Posting on a discussion thread does not create
|
||||
any Git artifact; the conversation lives in the app database.
|
||||
- **Contribution** is how an RFC *changes*. Editing the canonical
|
||||
body requires opening a branch and, eventually, a pull request.
|
||||
The pull request is the place a specific proposed change is
|
||||
reviewed and merged.
|
||||
|
||||
Reading both surfaces is open to anonymous visitors. Posting on
|
||||
either requires a contributor account.
|
||||
|
||||
---
|
||||
|
||||
## Working on a branch
|
||||
|
||||
Contribute mode flips one branch into edit-enabled. The centre
|
||||
column splits: a markdown source pane on the left, a live-rendered
|
||||
preview on the right. Fenced `mermaid` blocks render as diagrams in
|
||||
the preview.
|
||||
|
||||
Two kinds of edits accumulate on a branch:
|
||||
|
||||
- **AI-proposed changes.** You ask the AI a question or request a
|
||||
revision in the branch's chat. When the AI proposes a concrete
|
||||
edit, that edit appears as a *change card* in a panel below the
|
||||
chat — not yet applied to the document. You can **accept**,
|
||||
**decline**, or **edit before accepting**. Accepting produces
|
||||
one commit on the branch with the original text, the proposed
|
||||
text, and the AI's reason recorded in the commit body.
|
||||
- **Manual edits.** Typing directly into the source pane buffers
|
||||
locally and flushes as a single commit on an idle window, a
|
||||
branch switch, or an explicit "Save now" button. Manual edits
|
||||
also appear as change cards in the same panel — same evidence
|
||||
shape, different author.
|
||||
|
||||
Every accepted change is one commit. The framework does not
|
||||
support squash-merges or fixup-style cleanups: the per-change
|
||||
commit granularity is the framework's evidence unit, and
|
||||
collapsing it would erase what was earned.
|
||||
|
||||
### Discuss mode vs contribute mode
|
||||
|
||||
A branch defaults to discuss mode — read-only, with chat enabled.
|
||||
AI proposals still appear in chat, but they are *buffered* rather
|
||||
than applied; a single CTA invites you to flip the branch into
|
||||
contribute mode if you want to act on them. The toggle is an
|
||||
*intent* affordance, not a permission one. If you don't have push
|
||||
access to the branch, the toggle is disabled with a sign-in or
|
||||
request-access path.
|
||||
|
||||
`main` is special: contribute mode is never available there. The
|
||||
"Start Contributing" button on `main` always cuts a new branch.
|
||||
|
||||
### Flags
|
||||
|
||||
Anywhere you can read, you can drop a flag. A flag is the
|
||||
lightweight "I'm pointing at this, it's a problem" gesture — a
|
||||
single short declarative statement anchored to a passage. Creating
|
||||
a flag requires a contributor account but does not require push
|
||||
access to the branch: any signed-in contributor who can read a
|
||||
passage can point at it and say it's wrong.
|
||||
|
||||
Flags don't block PR merges by design — making them a merge gate
|
||||
would re-create the failure mode where contributors hastily "resolve"
|
||||
threads to unblock a button. Flags are prominent on PR headers but
|
||||
non-blocking.
|
||||
|
||||
### Branch visibility
|
||||
|
||||
A new branch is publicly readable by default. The branch creator
|
||||
can flip a branch to private, in which case only the creator, any
|
||||
explicit grantees, and the RFC's per-RFC owners and arbiters can
|
||||
read it. Owners and arbiters can flip it back.
|
||||
|
||||
**Opening a PR makes the branch fully public.** If your branch is
|
||||
currently private, the "Open PR" affordance asks you to confirm
|
||||
this before submitting. There is no concept of a private PR — the
|
||||
framework's evidence claim depends on the argument being readable.
|
||||
|
||||
### Who can push to a branch
|
||||
|
||||
Every branch has one of three contribute modes:
|
||||
|
||||
- **`just-me`** (default) — only the branch creator can push.
|
||||
- **`specific`** — only the branch creator and explicitly granted
|
||||
contributors can push.
|
||||
- **`any-contributor`** — any signed-in contributor can push.
|
||||
|
||||
The branch creator and the RFC's per-RFC owners and arbiters can
|
||||
change this setting at any time.
|
||||
|
||||
### Branch hygiene
|
||||
|
||||
A branch with no associated PR auto-closes after 30 days of
|
||||
inactivity. A closed branch is deleted from the Git host 60 days
|
||||
later. Closed branches remain in the catalog under a "show closed"
|
||||
filter — closing is a state, not a censorship event. The chat
|
||||
attached to a closed or deleted branch is preserved as historical
|
||||
record.
|
||||
|
||||
Owners and arbiters can *pin* a branch to disable the auto-close
|
||||
timer if the work is paused but legitimately ongoing.
|
||||
|
||||
---
|
||||
|
||||
## Opening and reviewing a pull request
|
||||
|
||||
A pull request is the deliberate "ready for review" gesture for
|
||||
work that has accumulated on a branch. The "Open PR" affordance is
|
||||
available on any branch with at least one commit ahead of `main`.
|
||||
|
||||
The PR creation modal collects two AI-drafted fields, both editable
|
||||
before submit:
|
||||
|
||||
- **Title.** A one-line description of the change, in spec voice.
|
||||
- **Description.** Two to four sentences pulling from the branch
|
||||
chat, written for an arbiter.
|
||||
|
||||
There is no reviewer picker. The RFC's arbiters are the implicit
|
||||
reviewer set.
|
||||
|
||||
### The PR review page
|
||||
|
||||
The review page shows the diff, the branch's compressed chat
|
||||
(messages that produced accepted changes are expanded, the rest is
|
||||
behind a "Show full conversation" toggle), and the review-comment
|
||||
surface inline below the chat.
|
||||
|
||||
Review comments are not a separate concept from chat — they live in
|
||||
the same thread, anchored to a range in the diff. The framework's
|
||||
claim is that the disagreement an arbiter raises about a proposed
|
||||
change is the same *kind* of thing as the disagreement that
|
||||
produced the proposed change in the first place, and the two should
|
||||
share a surface.
|
||||
|
||||
Each PR records a per-user seen-cursor. New diff hunks and new
|
||||
conversation messages since your last visit render with a subtle
|
||||
accent. The cursor advances on view; you do not have to mark
|
||||
anything as read.
|
||||
|
||||
### Merging a PR
|
||||
|
||||
Per-RFC owners and arbiters can merge; app-wide admins and owners
|
||||
also retain this capability. The merge produces a no-fast-forward
|
||||
commit on `main`, preserving every per-acceptance commit as an
|
||||
individually reachable node in `main`'s history.
|
||||
|
||||
Merge is hard-blocked **only** by Git-level conflicts with `main`.
|
||||
Open review threads, pending change-cards, unresolved chat threads,
|
||||
and open flags do not block merge by design.
|
||||
|
||||
### Conflicts with main
|
||||
|
||||
A conflict surfaces on the PR page as a read-only banner. A "Start
|
||||
resolution branch" affordance cuts a fresh branch off `main`'s
|
||||
current tip, replays the work into it (asking the AI to resolve
|
||||
unambiguous conflicts, surfacing the rest for you), and opens a new
|
||||
PR. The original PR auto-closes when the resolution PR merges.
|
||||
|
||||
Fixup commits on the existing branch are not supported. Per-change
|
||||
commit granularity is the framework's evidence unit; admitting
|
||||
"fix merge conflict with main" commits would dilute it.
|
||||
|
||||
---
|
||||
|
||||
## Graduation: super-draft → active RFC
|
||||
|
||||
Graduation is the moment a super-draft becomes a canonical entry
|
||||
in the catalog. It is initiated by an app-wide admin, an app-wide
|
||||
owner, or one of the RFC's per-RFC owners or arbiters from the
|
||||
super-draft's page.
|
||||
|
||||
Two preconditions block the action:
|
||||
|
||||
- **The super-draft must have at least one owner.** The proposer
|
||||
is automatically the first owner; if they have stepped away, any
|
||||
contributor can use the "Claim ownership" affordance to add
|
||||
themselves.
|
||||
- **No open body-edit PRs against the super-draft's entry.** An
|
||||
open body-edit PR would attempt to re-introduce a body to a
|
||||
frontmatter-only entry after graduation runs. Merge or withdraw
|
||||
them first.
|
||||
|
||||
When the dialog confirms, the framework runs a transactional
|
||||
sequence: create a fresh Git repository for the RFC, seed it with
|
||||
the super-draft's body as `RFC.md`, update the meta-repo entry to
|
||||
`state: active` with the integer ID and the new repository's URL,
|
||||
auto-merge that update. If any step fails partway, the sequence
|
||||
rolls back — the half-created repository is deleted and the
|
||||
unmerged update is abandoned. The dialog shows each step in flight
|
||||
and tells you exactly what happened.
|
||||
|
||||
The chat thread on the super-draft moves to the new repository's
|
||||
`main` chat at graduation. Edit-branch chats from the super-draft
|
||||
phase stay attached to their original branches on the meta repo
|
||||
and surface from the new RFC view under a "Pre-graduation history"
|
||||
section.
|
||||
|
||||
Graduation is not reversible. The path forward from an active RFC
|
||||
is withdrawal, not back to super-draft.
|
||||
|
||||
---
|
||||
|
||||
## Withdrawing and reopening
|
||||
|
||||
An active RFC or a super-draft can be withdrawn by the proposer
|
||||
(for a super-draft they proposed) or by an admin or owner. A
|
||||
withdrawn entry stays in the catalog as a historical record but is
|
||||
hidden from default views. The entry is filterable back in.
|
||||
|
||||
An admin or owner can reopen a withdrawn entry back into the
|
||||
super-draft state. The history is preserved across the transition.
|
||||
|
||||
---
|
||||
|
||||
## AI in the chat
|
||||
|
||||
The chat on every RFC, super-draft, branch, and PR has an AI
|
||||
participant by default. The framework treats the AI as one voice
|
||||
among many in a public argument — not an oracle, and not a
|
||||
co-author whose name lands on commits.
|
||||
|
||||
You invoke the AI by writing into the chat composer and submitting.
|
||||
Each message can pick a model from the picker (the option list is
|
||||
configurable per RFC). The AI responds in the chat; when its
|
||||
response includes a concrete change to the document, that change
|
||||
appears as a card you can accept, decline, or edit.
|
||||
|
||||
When you accept an AI's proposed change, the commit's
|
||||
`On-behalf-of:` trailer names *you*, not the AI. The AI's authorship
|
||||
survives only as evidence — the original proposal in the commit body
|
||||
and the message that produced it in the chat record. The framework
|
||||
is explicit about this: AI participation produces evidence; it does
|
||||
not produce authorship.
|
||||
|
||||
Two configuration knobs scope AI participation per RFC:
|
||||
|
||||
- **Which models are available.** The meta-repo entry's frontmatter
|
||||
carries an optional `models:` list. Absent means the RFC inherits
|
||||
whatever models the deployment is provisioned to run. An empty
|
||||
list (`models: []`) opts the RFC out of AI entirely — every AI
|
||||
surface is absent rather than disabled-but-present.
|
||||
- **Whose credentials pay.** By default the deployment operator's
|
||||
API credentials cover AI calls on every RFC. A `funder:`
|
||||
frontmatter field can name a single contributor whose registered
|
||||
credentials pay for AI calls on this RFC instead. The named
|
||||
contributor must explicitly consent from their settings page;
|
||||
either side can revoke at any time.
|
||||
|
||||
Per-RFC AI configuration is edited through the meta-repo PR flow
|
||||
that governs the rest of the entry's frontmatter — by the RFC's
|
||||
per-RFC owners and arbiters, or by app-wide admins or owners.
|
||||
|
||||
---
|
||||
|
||||
## Notifications
|
||||
|
||||
The framework's public-async work model produces signals that
|
||||
shouldn't all reach you the same way. Five surfaces compose:
|
||||
|
||||
- **In-app inbox.** The durable triage surface. One mental space
|
||||
across every RFC you have any relationship to, with per-RFC and
|
||||
per-category filters. Reachable from the inbox icon in the
|
||||
header.
|
||||
- **Badges.** Ambient pull-ins. A single integer beside the inbox
|
||||
icon (count of unread notifications). A small binary dot on
|
||||
individual catalog rows for watched RFCs with unseen activity.
|
||||
No per-row counts and no per-section counts.
|
||||
- **Toasts.** Transient mid-session signals. Used only for your own
|
||||
actions completing, and for events arriving on the view you're
|
||||
currently looking at.
|
||||
- **Email.** The single channel that escapes the app. Opt-in per
|
||||
category, conservative defaults. One-click unsubscribe per
|
||||
category.
|
||||
- **Digest.** Aggregation for activity on watched RFCs you haven't
|
||||
triaged through any other channel.
|
||||
|
||||
### Watch states
|
||||
|
||||
Every RFC has one of three implicit relationship states for you:
|
||||
|
||||
- **Watching.** You receive structural signals for the RFC.
|
||||
- **Following.** You receive only churn-grade signals (new
|
||||
commits, new chat messages on threads you didn't participate
|
||||
in). This is a lighter relationship than watching.
|
||||
- **Muted.** You receive no signals for the RFC. The mute is
|
||||
per-RFC and self-imposed; it does not affect what others see
|
||||
or what reaches you on *other* RFCs.
|
||||
|
||||
Watch states transition automatically based on your participation,
|
||||
with explicit overrides available from each RFC's header and from
|
||||
the notification settings page.
|
||||
|
||||
### Email categories
|
||||
|
||||
Four categories with distinct defaults:
|
||||
|
||||
- **Personal-direct events** — default on. Signals where you are
|
||||
the named subject. The contract is that when your name is on the
|
||||
action, the framework reaches out of band.
|
||||
- **Watched-RFC structural events** — default off. PR opened on a
|
||||
watched RFC, PR merged, graduation, withdrawal. Inbox and badges
|
||||
carry these by default; the email toggle is opt-in.
|
||||
- **Watched-RFC churn** — permanently off, by design. Per-commit
|
||||
and per-message email is intentionally not offered. The digest
|
||||
aggregates this activity weekly.
|
||||
- **Admin-actionable events** — default on for admins and owners,
|
||||
unused for contributors.
|
||||
|
||||
### Quiet hours
|
||||
|
||||
You can set a daily window during which email notifications are
|
||||
held. Messages held during the window are released at window end —
|
||||
bundled into a single "Activity while you were away" email if a
|
||||
threshold accumulated, otherwise sent individually.
|
||||
|
||||
---
|
||||
|
||||
## Roles & permissions
|
||||
|
||||
Authorization in this framework is owned by the app itself, not by
|
||||
the Git host. The Git host sees only a single bot account — every
|
||||
commit, every PR, every merge passes through it on a user's behalf
|
||||
— and the *app* decides which users are authorized to ask the bot
|
||||
to do which things.
|
||||
|
||||
### The four app-wide roles
|
||||
|
||||
Each role is a strict superset of the one below it.
|
||||
|
||||
1. **Anonymous.** Anyone who has not signed in. Can read public
|
||||
RFCs, public branches, and public PRs; cannot chat, propose,
|
||||
create branches, or open PRs.
|
||||
|
||||
2. **Contributor.** The default role for any authenticated
|
||||
account. Adds everything anonymous can do, plus: propose new
|
||||
RFCs, create branches on any RFC repository, open PRs from
|
||||
branches they have push access to, post on chat anywhere they
|
||||
can read, claim ownership of unclaimed super-drafts.
|
||||
|
||||
3. **Admin.** Adds the ability to act on any RFC, anywhere in the
|
||||
framework. Concretely: merge any PR on any RFC, graduate any
|
||||
super-draft, set branch visibility on anyone's behalf, withdraw
|
||||
or reopen any entry, write-mute or restore any contributor,
|
||||
grant or revoke the **admin** role.
|
||||
|
||||
4. **Owner.** Adds two capabilities admin does not have: grant or
|
||||
revoke the **owner** role itself, and disable an account
|
||||
entirely. The framework names a single "owner zero" at
|
||||
bootstrap.
|
||||
|
||||
The practical difference between admin and owner is narrow but
|
||||
load-bearing: admin is the operational tier — it does the day-to-
|
||||
day moderation and stewardship work; owner is the tier that
|
||||
controls the admin tier. Disabling an account and creating other
|
||||
owners are owner-only because they affect the framework's chain of
|
||||
authority itself.
|
||||
|
||||
The app refuses to let the last owner demote themselves silently —
|
||||
losing the last owner would leave nobody able to grant the role
|
||||
back. Role changes are recorded in an append-only `permission_events`
|
||||
log; an admin's own admin/users page shows the log of who promoted,
|
||||
demoted, or muted whom.
|
||||
|
||||
### Per-RFC delegated authority
|
||||
|
||||
The four roles above are framework-wide. Within an individual RFC,
|
||||
the meta-repo entry's frontmatter names two additional groups:
|
||||
|
||||
- **`owners:`** — contributors elevated for this RFC. They can
|
||||
grant push access on any branch in the RFC, merge any PR on the
|
||||
RFC, change branch visibility, and withdraw the RFC.
|
||||
- **`arbiters:`** — contributors with merge authority for this RFC.
|
||||
Functionally similar to per-RFC owners for merge decisions; the
|
||||
distinction matters in some configuration paths.
|
||||
|
||||
Per-RFC owners and arbiters are **not** app-wide admins. Their
|
||||
elevated powers are scoped strictly to the RFC named in the
|
||||
frontmatter. This is what lets the framework distribute work
|
||||
without putting one person on the hook for every action.
|
||||
|
||||
The proposer of an RFC is automatically the first per-RFC owner.
|
||||
Additional per-RFC owners are added through a "Claim ownership"
|
||||
PR against the meta repository; app-wide admins or owners merge
|
||||
it.
|
||||
|
||||
### Per-branch contribute grants
|
||||
|
||||
Within an RFC, the branch creator and the RFC's per-RFC owners
|
||||
and arbiters can grant push access to specific contributors on a
|
||||
specific branch — `specific` contribute mode, described under
|
||||
"Working on a branch."
|
||||
|
||||
### The write-mute
|
||||
|
||||
An app-wide admin or owner can **mute** a contributor. A muted
|
||||
account retains read access and keeps its existing branches, but
|
||||
cannot create new branches, open new PRs, propose new RFCs, or
|
||||
post chat. This is a moderation tool, distinct from removing the
|
||||
account; restoring is the reverse gesture.
|
||||
|
||||
The write-mute applies only to contributors. Promoting a user to
|
||||
admin or owner is the way to remove a user's write-restriction in
|
||||
the structural sense; the write-mute is for *retaining* an account
|
||||
while removing its ability to act.
|
||||
|
||||
Every mute and every restore is recorded in `permission_events`.
|
||||
|
||||
### Three different "mutes"
|
||||
|
||||
The word "mute" appears in three structurally distinct places.
|
||||
They share a word and nothing else.
|
||||
|
||||
- **Write-mute.** Admin-imposed. Removes a contributor's ability
|
||||
to post or push. Described above.
|
||||
- **Per-RFC notification mute.** Self-imposed. Sets your watch
|
||||
state on a specific RFC to *muted* — you stop receiving signals
|
||||
for that RFC, in inbox, badges, and email. Does not affect what
|
||||
others see.
|
||||
- **Per-user notification mute.** Self-imposed. Suppresses
|
||||
notifications produced by a specific other user, anywhere in
|
||||
the framework. Notification-volume only — it does not affect
|
||||
what you can read.
|
||||
|
||||
A write-muted contributor continues to receive notifications
|
||||
normally, so they can triage what they can't act on, and so a
|
||||
restore lands cleanly.
|
||||
|
||||
### Audit trail
|
||||
|
||||
Every gesture that changes app state — role changes, mutes,
|
||||
graduations, withdrawals, grant changes — is recorded in
|
||||
append-only logs the app maintains. Git commit history is for
|
||||
code archaeology; the app's audit log is the accountability
|
||||
record. An admin's page surfaces both `permission_events` (the
|
||||
role/mute log) and `actions` (the state-transition log) for
|
||||
review.
|
||||
|
||||
---
|
||||
|
||||
## Where to learn more
|
||||
|
||||
- The framework's *why* lives in [the philosophy
|
||||
document](/philosophy).
|
||||
- The binding technical contract — section numbers (`§n.n`)
|
||||
referenced throughout this guide — is in `SPEC.md` in the
|
||||
framework's source repository.
|
||||
- Deployment operators have their own recipe in
|
||||
`docs/DEPLOYMENTS.md`.
|
||||
@@ -356,18 +356,37 @@ merge with no data movement.
|
||||
|
||||
Authorization is owned by the app. Gitea sees only the bot account.
|
||||
|
||||
Authentication, as of v0.7.0, is by email + one-time-code: a visitor
|
||||
enters their email address, receives a six-digit code via SMTP, and
|
||||
exchanges the code for a session. The Gitea OAuth callback that
|
||||
v0.1 used as the human sign-in path remains as a migration fallback
|
||||
during the v0.7.0 window — `users.gitea_id` is preserved on existing
|
||||
rows so a grandfathered user signing in via either path resolves to
|
||||
the same row — but the primary surface points at OTC. `users.email`
|
||||
is the identity key for everything provisioned after v0.7.0;
|
||||
`users.gitea_id` is the grandfathering linker (nullable, partial-
|
||||
unique). The Gitea bot user + token are still required for server-
|
||||
side git operations (repo reads, PR creation); only the operator-
|
||||
facing sign-in surface moved.
|
||||
Authentication has three paths, in the order a visitor encounters
|
||||
them:
|
||||
|
||||
1. **Email + one-time code (OTC).** The v0.7.0 primary path: a
|
||||
visitor enters their email address, receives a six-digit code via
|
||||
SMTP, and exchanges the code for a session. Used by every visitor
|
||||
on first sign-in, and as the fallback for the other two paths.
|
||||
2. **Email + passcode (with OTC fallback).** Added in v0.10.0
|
||||
(roadmap item #8). After a successful OTC sign-in, the visitor
|
||||
may set a user-chosen passcode (4–20 characters, bcrypt-hashed at
|
||||
rest) and use email + passcode on subsequent sign-ins. Five
|
||||
consecutive failed verifies lock the passcode path for 15 minutes
|
||||
(HTTP 423); during the lockout the user falls back to OTC. The
|
||||
OTC path is unaffected by the passcode lockout, so a forgotten
|
||||
passcode is recovered by requesting a fresh OTC — there is no
|
||||
separate "forgot passcode" flow. The user can remove the passcode
|
||||
at any time from the §6.2 sign-in settings tab, returning to
|
||||
OTC-only.
|
||||
3. **Gitea OAuth fallback (migration only).** The v0.1 OAuth
|
||||
callback remains functional during the v0.7.0 window, with a
|
||||
small "Sign in with Gitea (fallback)" link on `/login` so users
|
||||
with active OAuth sessions or older invite paths still have a
|
||||
way in. Scheduled for removal in a future release per §19.2.
|
||||
|
||||
`users.gitea_id` is preserved on existing rows so a grandfathered
|
||||
user signing in via any of the three paths resolves to the same row.
|
||||
`users.email` is the identity key for everything provisioned after
|
||||
v0.7.0; `users.gitea_id` is the grandfathering linker (nullable,
|
||||
partial-unique). The Gitea bot user + token are still required for
|
||||
server-side git operations (repo reads, PR creation); only the
|
||||
operator-facing sign-in surface moved.
|
||||
|
||||
Admission, as of v0.8.0, is by admin grant. v0.7.0 carried the
|
||||
v0.3.0 `allowed_emails` table forward as the admission gate at the
|
||||
@@ -2035,6 +2054,30 @@ with Gitea"; v0.7.0's email/OTC surface replaced that as the primary
|
||||
gesture, with a small "Sign in with Gitea (fallback)" link surviving
|
||||
on `/login` itself for the migration window.
|
||||
|
||||
`/login` itself is a stepped surface, driven by which auth path the
|
||||
viewer is currently on (§6):
|
||||
|
||||
1. **Email step.** The viewer enters their email. The frontend
|
||||
consults `GET /auth/passcode/check?email=…` to learn whether
|
||||
this email has a passcode set. The check endpoint is
|
||||
account-enumeration-safe — it returns `has_passcode: false` for
|
||||
both "unknown email" and "known email without passcode", so a
|
||||
probing client cannot distinguish the two from the response.
|
||||
2. **Either the passcode step or the OTC code step.** If the email
|
||||
has a passcode set, the viewer is asked for it (v0.10.0).
|
||||
Otherwise an OTC is dispatched and the viewer is asked for the
|
||||
six-digit code from their email (v0.7.0).
|
||||
3. **Optional post-OTC passcode-offer step.** After a successful
|
||||
OTC verify on an account with no passcode set, the surface
|
||||
asks "Set a passcode for faster sign-in next time?" — the user
|
||||
can dismiss the offer or set one inline. The skip-for-now path
|
||||
redirects straight to `/`.
|
||||
|
||||
The passcode step carries a "Use a code instead" link that
|
||||
re-dispatches an OTC and switches to the code step — the same path
|
||||
the lockout response (HTTP 423) takes automatically after five
|
||||
consecutive failed passcode verifies.
|
||||
|
||||
This is the front door. It sets expectation before the user encounters
|
||||
the mechanics, so the mechanics (super-drafts, graduation, public
|
||||
arguments, AI participation in chat) read as load-bearing rather than
|
||||
@@ -2698,9 +2741,19 @@ The follow-up session will refine this. A minimal starting set:
|
||||
silently if the email wasn't on the `allowed_emails` list (the
|
||||
v0.3.0 admission gate); v0.8.0 (item #6) removed that check —
|
||||
admission moved to `permission_state` on the freshly-provisioned
|
||||
`users` row, asserted at the contributor gate. Per §19.2's
|
||||
expected next session, this endpoint is the lead-up to the
|
||||
Cloudflare-Turnstile abuse-mitigation overlay.
|
||||
`users` row, asserted at the contributor gate. v0.12.0 (item #10)
|
||||
gates this endpoint behind a CloudFlare Turnstile siteverify call:
|
||||
the body carries an optional `turnstile_token` field, the server
|
||||
POSTs `secret` + `response` to `challenges.cloudflare.com/turnstile/
|
||||
v0/siteverify` before the bcrypt hash + SMTP send, and a failed
|
||||
challenge refuses with HTTP 400 spending no rate budget. Two env
|
||||
vars drive the policy: `CLOUDFLARE_TURNSTILE_SECRET` (Secret
|
||||
Manager) and `TURNSTILE_REQUIRED` (overlay, default `false`). When
|
||||
the secret is unset and `TURNSTILE_REQUIRED=false`, the gate is
|
||||
open (the dev / pre-rollout path); when the secret is unset and
|
||||
`TURNSTILE_REQUIRED=true`, the endpoint refuses with HTTP 500
|
||||
"auth misconfigured" so a future config drift fails loudly
|
||||
instead of silently disabling abuse defense.
|
||||
- `POST /auth/otc/verify` — unauthenticated. Body carries `email` and
|
||||
`code`. Validates the bcrypt hash against the most-recent unconsumed
|
||||
non-expired row for the email, marks the row consumed, provisions
|
||||
@@ -2728,6 +2781,38 @@ The follow-up session will refine this. A minimal starting set:
|
||||
v0.8.0 — the first-OTC profile-capture endpoint (roadmap item
|
||||
#6). v0.9.0's admin user-management page consumes this column
|
||||
set to render the request queue.
|
||||
- `GET /auth/passcode/check` — unauthenticated. Query param `email`.
|
||||
Returns `{has_passcode: boolean}`. The frontend's `/login` surface
|
||||
calls this after the email step to decide whether to render a
|
||||
passcode input or fall back to OTC. The response carries only the
|
||||
boolean; lockout state, the bcrypt hash, and the `passcode_set_at`
|
||||
stamp are not leaked. An unknown email and a known-without-passcode
|
||||
email both return `false`, so the endpoint is enumeration-safe.
|
||||
- `POST /auth/passcode/set` — authenticated (any role). Body carries
|
||||
`passcode` (4–20 characters). bcrypt-hashes the passcode, writes
|
||||
`users.passcode_hash` + `users.passcode_set_at`, clears the failure
|
||||
counter and any active lockout. Refuses obvious patterns (a small
|
||||
denylist: `0000`, `1234`, `aaaa`, `password`, etc.) and length
|
||||
violations with HTTP 422. Replaces any prior passcode. v0.10.0.
|
||||
- `DELETE /auth/passcode` — authenticated. Clears
|
||||
`users.passcode_hash` and `users.passcode_set_at`, returning the
|
||||
user to OTC-only on next sign-in. v0.10.0.
|
||||
- `POST /auth/passcode/verify` — unauthenticated. Body carries
|
||||
`email` and `passcode`. Locates the user, checks the lockout
|
||||
window, and compares via bcrypt. On success: clears the failure
|
||||
counter, refreshes `last_seen_at`, stores the session cookie,
|
||||
returns HTTP 200 with the minimal user payload. On failure:
|
||||
increments `passcode_failed_attempts`. After five consecutive
|
||||
failures, stamps `passcode_locked_until = now + 15 minutes` and
|
||||
returns HTTP 423 with a `locked_until` field; subsequent attempts
|
||||
inside the window are refused with the same shape. After the
|
||||
window expires, the next attempt clears the counter and proceeds
|
||||
normally. The OTC path (§17 above) is unaffected by the passcode
|
||||
lockout — a locked-out user can still request and verify a fresh
|
||||
OTC. The wrong-passcode and unknown-email failure modes both
|
||||
return HTTP 400 with a generic message; the no-passcode-set
|
||||
failure also collapses to 400 so the response does not enumerate
|
||||
account state. v0.10.0.
|
||||
- `GET /api/rfcs` — list entries with state, id, title, slug, repo,
|
||||
owners, last_active_at, has_open_prs, starred-by-me. Supports
|
||||
search, sort, filter chips, and the `unclaimed` predicate.
|
||||
@@ -3785,34 +3870,84 @@ Candidates surfaced during v0.8.0 (open beta-access request flow,
|
||||
its session once the OTC adoption curve flattens.
|
||||
- **Device trust (30-day skip).** *Surfaced by v0.7.0 — the
|
||||
signed-in cookie already lasts 30 days via SessionMiddleware,
|
||||
but every sign-in still requires a fresh OTC.* The roadmap
|
||||
item-#9 candidate adds a "trust this device" affordance on the
|
||||
verify step that issues a longer-lived rotating token, so
|
||||
returning visitors on the same device skip the OTC step. The
|
||||
shape question is whether the trust is a signed cookie distinct
|
||||
from the session, a row in a `device_trust` table keyed by a
|
||||
random device-id, or a property of the session itself; and
|
||||
whether the trust survives password-equivalent events (none
|
||||
exist yet — passcodes are item #8 / v0.10.0) or only survives
|
||||
explicit logout. Earns its session as the v0.11.0 design pass.
|
||||
- **Cloudflare Turnstile (or equivalent) on `/auth/otc/request`.**
|
||||
*Surfaced by v0.7.0 — the endpoint is now the new abuse hot
|
||||
path.* Per-email cooldown stops the trivial loop; what it
|
||||
doesn't stop is a distributed scrape that fans out across a
|
||||
large invitee list to harvest the "this email is admitted vs.
|
||||
this email is not" signal indirectly (timing differences, SMTP
|
||||
bounce-rate observation). The roadmap item-#10 candidate gates
|
||||
the request endpoint behind a one-step browser-side challenge
|
||||
before the bcrypt hash + SMTP send. Open questions: which
|
||||
provider (Turnstile is the default since it's free and
|
||||
privacy-respecting; hCaptcha and reCAPTCHA are also viable);
|
||||
how the deployment configures it (`TURNSTILE_SITE_KEY` +
|
||||
`TURNSTILE_SECRET_KEY` env vars, gated by `if
|
||||
config.turnstile_site_key:` at the handler so existing
|
||||
deployments don't break); whether the verify endpoint also
|
||||
gets a challenge (probably yes for parity); and how the test
|
||||
harness mocks the challenge. Earns its session as the v0.12.0
|
||||
design pass.
|
||||
but every sign-in still requires a fresh OTC or passcode.* The
|
||||
roadmap item-#9 candidate adds a "trust this device" affordance
|
||||
on the verify step that issues a longer-lived rotating token,
|
||||
so returning visitors on the same device skip both the OTC and
|
||||
the passcode step. The shape question is whether the trust is a
|
||||
signed cookie distinct from the session, a row in a `device_trust`
|
||||
table keyed by a random device-id, or a property of the session
|
||||
itself; and whether the trust survives password-equivalent events
|
||||
— v0.10.0's passcode-change and passcode-clear gestures are the
|
||||
v1 instances — or only survives explicit logout. Earns its
|
||||
session as the v0.11.0 design pass.
|
||||
- **Cloudflare Turnstile on `/auth/otc/request`.** *Settled in
|
||||
v0.12.0 (roadmap item #10).* The OTC request endpoint is now
|
||||
gated behind a Turnstile siteverify call: the frontend renders
|
||||
the official widget on the `/login` email-entry step (and on the
|
||||
passcode step for the "Use a code instead" fallback dispatch),
|
||||
the captured token rides in the request body as
|
||||
`turnstile_token`, and the backend POSTs `secret` + `response`
|
||||
to `challenges.cloudflare.com/turnstile/v0/siteverify` before
|
||||
the bcrypt hash + SMTP send. The widget renders only on the
|
||||
email-entry / passcode-fallback dispatch points — the OTC
|
||||
verify step is bottlenecked on email delivery and protected by
|
||||
the five-minute TTL + single-use row consume, so a second
|
||||
challenge there would double the rate budget against the same
|
||||
abuse path without measurably more protection (revisit if bots
|
||||
adapt to the email-entry challenge specifically). Configured
|
||||
via `CLOUDFLARE_TURNSTILE_SECRET` (Secret Manager) and
|
||||
`VITE_TURNSTILE_SITE_KEY` (frontend build-time overlay); a
|
||||
third var `TURNSTILE_REQUIRED` (default `false`) lets the
|
||||
operator flip from "soft-fail when secret unset" (the dev /
|
||||
pre-rollout shape) to "fail-closed when secret unset" (HTTP 500
|
||||
"auth misconfigured", the production-locked shape). Tests mock
|
||||
the siteverify HTTP call at the `httpx.post` boundary in
|
||||
`app.turnstile`. The hCaptcha / reCAPTCHA alternatives noted in
|
||||
the v0.7.0 surfacing are still viable substitutes for a future
|
||||
deployment that wants them but the framework's tested path is
|
||||
Turnstile.
|
||||
|
||||
Candidates surfaced during v0.10.0 (user-set passcodes, §6.2 /
|
||||
roadmap item #8):
|
||||
|
||||
- **Passcode policy tunables via env.** v0.10.0 hard-codes the
|
||||
lockout shape (5 consecutive failures → 15-minute lockout) and
|
||||
the min/max passcode length (4 / 20) in
|
||||
`backend/app/passcode.py`. The denylist of obvious patterns is
|
||||
also hard-coded. A deployment that wants tighter or looser rules
|
||||
has to fork the constants. Two env vars
|
||||
(`PASSCODE_LOCKOUT_AFTER_ATTEMPTS`,
|
||||
`PASSCODE_LOCKOUT_DURATION_MINUTES`) would let operators
|
||||
reshape the lockout without forking; a third
|
||||
(`PASSCODE_MIN_LENGTH`) would cover the length floor. Earns its
|
||||
session if a deployment surfaces evidence that the v1 defaults
|
||||
bite.
|
||||
- **Per-IP rate-limiting on `/auth/passcode/verify`.** v0.10.0's
|
||||
lockout is per-account: 5 failures against the same email lock
|
||||
that account for 15 minutes. A distributed attacker that knows
|
||||
many emails can fan out across them without ever tripping any
|
||||
one account's lockout. Adding a per-IP throttle (e.g., 30
|
||||
passcode-verify attempts / minute / IP, returning HTTP 429) is
|
||||
the natural pairing. Defer-able — the per-account lockout is
|
||||
the v1 shape that closes the loud-loop case; the per-IP
|
||||
distributed case waits on evidence. Touches §6.2 and §17.
|
||||
- **Passcode-change "still know your old passcode" challenge.**
|
||||
v0.10.0 lets a signed-in user replace their passcode from
|
||||
`/settings/notifications` without re-entering the old one — the
|
||||
session is sufficient. A future hardening pass may require the
|
||||
old passcode (or a fresh OTC verify) before accepting the
|
||||
change, to mitigate session-hijack scenarios where the attacker
|
||||
rotates the passcode to lock the legitimate owner out. The same
|
||||
question applies to the clear gesture. Earns its session if
|
||||
session-hijack becomes a real threat surface.
|
||||
- **Passkey / WebAuthn.** A much heavier next step than passcodes:
|
||||
hardware-backed device credentials that resist phishing. The
|
||||
v0.10.0 passcode shape is a stopgap for the "I'd rather not
|
||||
type a code every time" ergonomic problem; passkeys are the
|
||||
long-term answer. Out of scope for the current roadmap —
|
||||
earns a dedicated session if/when the deployment grows enough
|
||||
that the phishing surface justifies the integration cost.
|
||||
|
||||
Candidates surfaced during v0.13.0 (cookie / privacy consent, §14.5
|
||||
and §14.6):
|
||||
|
||||
@@ -92,3 +92,21 @@ OTC_TTL_MINUTES=10
|
||||
# loud-failure shape so the abuse path is visible). Set to 0 to
|
||||
# disable the cooldown — useful for tests but never in production.
|
||||
OTC_REQUEST_COOLDOWN_SECONDS=60
|
||||
|
||||
# --- v0.12.0: CloudFlare Turnstile gate on OTC dispatch (§6.2, item #10) ---
|
||||
# Provision a Turnstile site at dash.cloudflare.com → Turnstile → Add
|
||||
# site. The site key (public) goes in `frontend/.env` as
|
||||
# VITE_TURNSTILE_SITE_KEY. The secret key (private) goes here and is
|
||||
# what the backend POSTs to /siteverify alongside the user's response
|
||||
# token. Leave both unset for dev/test paths; the gate stays open when
|
||||
# the secret is absent AND TURNSTILE_REQUIRED=false (the default).
|
||||
CLOUDFLARE_TURNSTILE_SECRET=
|
||||
|
||||
# When `true`, /auth/otc/request fails closed (HTTP 500 "auth
|
||||
# misconfigured") if CLOUDFLARE_TURNSTILE_SECRET is unset. When `false`
|
||||
# (the default), a missing secret skips verification — useful in dev
|
||||
# and during the pre-rollout window when the operator hasn't wired
|
||||
# the secret yet. Flip to `true` once the secret is wired so a future
|
||||
# config drift surfaces as a loud 500 rather than a silent abuse-
|
||||
# defense disablement.
|
||||
TURNSTILE_REQUIRED=false
|
||||
|
||||
+21
-6
@@ -26,6 +26,7 @@ from . import (
|
||||
api_prs,
|
||||
auth,
|
||||
db,
|
||||
docs as docs_mod,
|
||||
entry as entry_mod,
|
||||
cache,
|
||||
funder,
|
||||
@@ -122,6 +123,17 @@ def make_router(
|
||||
payload = philosophy.load()
|
||||
return {"body": payload["body"]}
|
||||
|
||||
# ---------------------------------------------------------------
|
||||
# /api/docs — DOCS.md served verbatim. Sibling of /api/philosophy:
|
||||
# no auth gate, same disk-first load + cache shape, same intent —
|
||||
# public read surface for a markdown file checked into the repo.
|
||||
# ---------------------------------------------------------------
|
||||
|
||||
@router.get("/api/docs")
|
||||
async def get_docs() -> dict[str, Any]:
|
||||
payload = docs_mod.load()
|
||||
return {"body": payload["body"]}
|
||||
|
||||
# ---------------------------------------------------------------
|
||||
# Auth surface — reads role from our users table per §6.
|
||||
# ---------------------------------------------------------------
|
||||
@@ -131,13 +143,12 @@ def make_router(
|
||||
user = auth.current_user(request)
|
||||
if user is None:
|
||||
return {"authenticated": False, "user": None}
|
||||
# v0.8.0: surface `permission_state` plus the capture-flow
|
||||
# readiness signal (`needs_profile`). The frontend gates
|
||||
# the /beta-pending page and the inline banner off these
|
||||
# fields, and decides whether to prompt for the first/last/why
|
||||
# capture on first OTC sign-in.
|
||||
# v0.8.0 + v0.10.0: single round-trip for everything the
|
||||
# frontend gates UI off of — beta-access state + passcode state.
|
||||
row = db.conn().execute(
|
||||
"SELECT first_name, last_name, beta_request_reason FROM users WHERE id = ?",
|
||||
"SELECT first_name, last_name, beta_request_reason, "
|
||||
"passcode_hash, passcode_set_at "
|
||||
"FROM users WHERE id = ?",
|
||||
(user.user_id,),
|
||||
).fetchone()
|
||||
first_name = (row["first_name"] if row else None) or ""
|
||||
@@ -153,6 +164,8 @@ def make_router(
|
||||
and not last_name
|
||||
and not beta_request_reason
|
||||
)
|
||||
has_passcode = bool(row and row["passcode_hash"])
|
||||
passcode_set_at = row["passcode_set_at"] if (row and has_passcode) else None
|
||||
return {
|
||||
"authenticated": True,
|
||||
"user": {
|
||||
@@ -167,6 +180,8 @@ def make_router(
|
||||
"last_name": last_name,
|
||||
"beta_request_reason": beta_request_reason,
|
||||
"needs_profile": needs_profile,
|
||||
"has_passcode": has_passcode,
|
||||
"passcode_set_at": passcode_set_at,
|
||||
},
|
||||
}
|
||||
|
||||
|
||||
@@ -0,0 +1,61 @@
|
||||
"""User-facing docs source.
|
||||
|
||||
Mirrors `philosophy.py` shape. Serves `DOCS.md` from the repo root —
|
||||
the framework's plain-prose user guide to roles, contribution flow,
|
||||
and notification surfaces, distinct from the binding `SPEC.md`. Read
|
||||
from disk on first call and cached in-process; the periodic
|
||||
reconciler can call `refresh()` to pick up out-of-band edits.
|
||||
|
||||
`DOCS_PATH` overrides the default location if a deployment hosts the
|
||||
file elsewhere (a meta-repo working-tree clone, a sync target, etc.).
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
import logging
|
||||
import os
|
||||
import threading
|
||||
from pathlib import Path
|
||||
|
||||
log = logging.getLogger(__name__)
|
||||
|
||||
|
||||
_DEFAULT_PATH = Path(__file__).resolve().parents[2] / "DOCS.md"
|
||||
|
||||
_lock = threading.Lock()
|
||||
_cache: dict | None = None
|
||||
|
||||
|
||||
def _resolved_path() -> Path:
|
||||
override = os.environ.get("DOCS_PATH", "").strip()
|
||||
if override:
|
||||
return Path(override).expanduser().resolve()
|
||||
return _DEFAULT_PATH
|
||||
|
||||
|
||||
def load(force: bool = False) -> dict:
|
||||
"""Return the cached `{body, path, mtime}` payload, reading from disk
|
||||
on first call or when `force=True`.
|
||||
"""
|
||||
global _cache
|
||||
with _lock:
|
||||
if _cache is not None and not force:
|
||||
return _cache
|
||||
path = _resolved_path()
|
||||
try:
|
||||
text = path.read_text(encoding="utf-8")
|
||||
mtime = path.stat().st_mtime
|
||||
except FileNotFoundError:
|
||||
log.warning("DOCS.md not found at %s — serving placeholder", path)
|
||||
text = (
|
||||
"# DOCS.md not found\n\n"
|
||||
"The deployment is missing its user guide. Set "
|
||||
"DOCS_PATH or place DOCS.md at the project root."
|
||||
)
|
||||
mtime = 0.0
|
||||
_cache = {"body": text, "path": str(path), "mtime": mtime}
|
||||
return _cache
|
||||
|
||||
|
||||
def refresh() -> dict:
|
||||
"""Force-reread from disk. Returns the new payload."""
|
||||
return load(force=True)
|
||||
+108
-1
@@ -24,7 +24,9 @@ from . import (
|
||||
email_otc,
|
||||
hygiene,
|
||||
otc,
|
||||
passcode as passcode_mod,
|
||||
providers as providers_mod,
|
||||
turnstile,
|
||||
webhooks,
|
||||
)
|
||||
from .bot import Bot
|
||||
@@ -37,6 +39,14 @@ log = logging.getLogger("rfc_app")
|
||||
|
||||
class OtcRequestBody(BaseModel):
|
||||
email: str = Field(min_length=3, max_length=320)
|
||||
# v0.12.0 / roadmap item #10: CloudFlare Turnstile token from the
|
||||
# frontend widget. Optional in the body so a deployment that has
|
||||
# not yet wired the Turnstile site key (or a dev environment with
|
||||
# the widget intentionally skipped) still routes through the same
|
||||
# endpoint; the backend turnstile.verify_token call decides whether
|
||||
# to admit the request based on `TURNSTILE_REQUIRED` + presence of
|
||||
# the secret.
|
||||
turnstile_token: str | None = Field(default=None, max_length=4096)
|
||||
|
||||
|
||||
class OtcVerifyBody(BaseModel):
|
||||
@@ -44,6 +54,15 @@ class OtcVerifyBody(BaseModel):
|
||||
code: str = Field(min_length=1, max_length=16)
|
||||
|
||||
|
||||
class PasscodeSetBody(BaseModel):
|
||||
passcode: str = Field(min_length=1, max_length=64)
|
||||
|
||||
|
||||
class PasscodeVerifyBody(BaseModel):
|
||||
email: str = Field(min_length=3, max_length=320)
|
||||
passcode: str = Field(min_length=1, max_length=64)
|
||||
|
||||
|
||||
@asynccontextmanager
|
||||
async def lifespan(app: FastAPI):
|
||||
config = load_config()
|
||||
@@ -154,7 +173,27 @@ def _oauth_router(config) -> APIRouter:
|
||||
# ---------------------------------------------------------------
|
||||
|
||||
@router.post("/auth/otc/request")
|
||||
async def otc_request(body: OtcRequestBody):
|
||||
async def otc_request(body: OtcRequestBody, request: Request):
|
||||
# v0.12.0 / roadmap item #10: gate the request on a successful
|
||||
# Turnstile siteverify before the bcrypt hash + SMTP send. The
|
||||
# check runs first so a failed challenge spends no rate budget
|
||||
# and produces no envelope. When the operator has not wired the
|
||||
# secret AND TURNSTILE_REQUIRED=false (the default), the gate
|
||||
# opens — see `backend/app/turnstile.py` for the full matrix.
|
||||
client_ip = request.client.host if request.client else None
|
||||
ts = turnstile.verify_token(body.turnstile_token, client_ip=client_ip)
|
||||
if not ts.ok:
|
||||
if ts.reason == "misconfigured":
|
||||
# TURNSTILE_REQUIRED=true but the secret is unset. This
|
||||
# is an operator/config problem, not a client problem;
|
||||
# surface as 500 so the operator notices in their logs
|
||||
# rather than blaming the user's browser.
|
||||
raise HTTPException(500, "auth misconfigured")
|
||||
# missing-token / failed / network → uniform 400 so the
|
||||
# response does not enumerate which leg of the challenge
|
||||
# broke. The reason is in the server logs.
|
||||
raise HTTPException(400, "verification failed")
|
||||
|
||||
outcome = otc.request_code(body.email)
|
||||
if outcome.reason == "cooldown":
|
||||
# Loud failure per the rate-limit primitive — the abuse
|
||||
@@ -204,4 +243,72 @@ def _oauth_router(config) -> APIRouter:
|
||||
"needs_profile": needs_profile,
|
||||
}
|
||||
|
||||
# ---------------------------------------------------------------
|
||||
# v0.10.0: user-set passcodes after OTC (§6.2, roadmap item #8).
|
||||
#
|
||||
# After a successful OTC sign-in, a contributor may set a passcode
|
||||
# and use email + passcode for subsequent sign-ins. OTC remains the
|
||||
# forgot-passcode fallback — a verify failure beyond 5 consecutive
|
||||
# attempts locks the passcode path for 15 minutes; the OTC path is
|
||||
# unaffected by the lockout.
|
||||
# ---------------------------------------------------------------
|
||||
|
||||
@router.get("/auth/passcode/check")
|
||||
async def passcode_check(email: str = ""):
|
||||
"""Does this email have a passcode set? Anonymous endpoint —
|
||||
the Login.jsx flow calls this after the user types their email
|
||||
to decide whether to render a passcode input or fall back to
|
||||
OTC. We surface only the boolean; lockout state, the hash, and
|
||||
the set-at stamp are not leaked here."""
|
||||
status = passcode_mod.passcode_status(email)
|
||||
return {"has_passcode": status.has_passcode}
|
||||
|
||||
@router.post("/auth/passcode/set")
|
||||
async def passcode_set(body: PasscodeSetBody, request: Request):
|
||||
"""Set or replace the signed-in user's passcode. Requires an
|
||||
active session (OTC- or passcode-authenticated)."""
|
||||
user = auth.require_user(request)
|
||||
try:
|
||||
passcode_mod.set_passcode(user.user_id, body.passcode)
|
||||
except passcode_mod.PasscodeValidationError as e:
|
||||
raise HTTPException(422, str(e))
|
||||
return {"ok": True}
|
||||
|
||||
@router.delete("/auth/passcode")
|
||||
async def passcode_delete(request: Request):
|
||||
"""Remove the signed-in user's passcode. The user is back to
|
||||
OTC-only on next sign-in."""
|
||||
user = auth.require_user(request)
|
||||
passcode_mod.clear_passcode(user.user_id)
|
||||
return {"ok": True}
|
||||
|
||||
@router.post("/auth/passcode/verify")
|
||||
async def passcode_verify(body: PasscodeVerifyBody, request: Request):
|
||||
"""Sign in with email + passcode. Returns the standard session
|
||||
payload on success; HTTP 423 with `locked_until` when the
|
||||
account is in the lockout window; HTTP 400 for every other
|
||||
failure (the wrong-vs-unknown distinction is intentionally
|
||||
collapsed so a probing client cannot enumerate emails)."""
|
||||
result = passcode_mod.verify_passcode(body.email, body.passcode)
|
||||
if result.reason == "locked":
|
||||
raise HTTPException(
|
||||
423,
|
||||
{
|
||||
"detail": "Too many failed attempts; sign in with a one-time code instead",
|
||||
"locked_until": result.locked_until,
|
||||
},
|
||||
)
|
||||
if not result.ok or result.user is None:
|
||||
raise HTTPException(400, "Invalid passcode")
|
||||
auth.store_session(request, result.user)
|
||||
return {
|
||||
"ok": True,
|
||||
"user": {
|
||||
"id": result.user.user_id,
|
||||
"display_name": result.user.display_name,
|
||||
"email": result.user.email,
|
||||
"role": result.user.role,
|
||||
},
|
||||
}
|
||||
|
||||
return router
|
||||
|
||||
@@ -0,0 +1,367 @@
|
||||
"""§6.2 / v0.10.0: user-set passcodes after OTC (roadmap item #8).
|
||||
|
||||
After a successful OTC sign-in, a contributor may set a passcode and
|
||||
use email + passcode for subsequent sign-ins. OTC remains the fallback
|
||||
— a forgotten passcode is recovered by requesting a fresh OTC.
|
||||
|
||||
This module is the state machine behind the four `/auth/passcode/*`
|
||||
endpoints (`set`, `clear`, `verify`, `check`). The endpoints in
|
||||
`main.py` thin-wrap these helpers in the same shape the OTC module
|
||||
uses (see `otc.py`).
|
||||
|
||||
Shape:
|
||||
|
||||
* `set_passcode(user_id, passcode)` — bcrypt-hash the passcode and
|
||||
write it to `users.passcode_hash` + `users.passcode_set_at`.
|
||||
Validation (length, denylist) happens here, not at the endpoint,
|
||||
so the rule lives in one place. Replaces any prior passcode.
|
||||
* `clear_passcode(user_id)` — null out `passcode_hash` and
|
||||
`passcode_set_at`. The user is back to OTC-only.
|
||||
* `verify_passcode(email, passcode)` — locate the user by email,
|
||||
check lockout, compare via bcrypt, manage the failure counter,
|
||||
and return a populated `SessionUser` on success.
|
||||
* `passcode_status(email)` — does this email have a passcode set?
|
||||
Used by the `/auth/passcode/check` endpoint that the Login.jsx
|
||||
flow consults after the user types their email.
|
||||
|
||||
Lockout is a v1 shape: 5 consecutive failures sets
|
||||
`passcode_locked_until` to `now + 15 minutes`, after which a verify
|
||||
attempt that lands inside the window returns HTTP 423. The OTC path
|
||||
is unaffected by the lockout — a user can request and verify a fresh
|
||||
OTC to sign in while their passcode is locked out, and `verify_code`
|
||||
in `otc.py` does not consult these columns.
|
||||
|
||||
The lockout window and the failure threshold are hard-coded here.
|
||||
Tuning them via env vars (or moving to per-IP rate-limiting) is a
|
||||
§19.2 candidate; see SPEC §19.2.
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
import logging
|
||||
from dataclasses import dataclass
|
||||
|
||||
import bcrypt
|
||||
|
||||
from . import db
|
||||
from .auth import SessionUser
|
||||
|
||||
log = logging.getLogger(__name__)
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Tunables — intentionally hard-coded in v0.10.0 (see module docstring).
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
LOCKOUT_AFTER_FAILED_ATTEMPTS = 5
|
||||
LOCKOUT_DURATION_MINUTES = 15
|
||||
|
||||
PASSCODE_MIN_LENGTH = 4
|
||||
PASSCODE_MAX_LENGTH = 20
|
||||
|
||||
# A small denylist of patterns we never want a passcode to be. The
|
||||
# rule is "no obvious patterns"; the list is deliberately small —
|
||||
# every entry here is a verbatim string match. A heavier check
|
||||
# (sequential digits, single-character runs of length >= N, etc.)
|
||||
# is a §19.2 candidate.
|
||||
PASSCODE_DENYLIST: frozenset[str] = frozenset(
|
||||
{
|
||||
"0000",
|
||||
"1111",
|
||||
"2222",
|
||||
"3333",
|
||||
"4444",
|
||||
"5555",
|
||||
"6666",
|
||||
"7777",
|
||||
"8888",
|
||||
"9999",
|
||||
"1234",
|
||||
"12345",
|
||||
"123456",
|
||||
"1234567",
|
||||
"12345678",
|
||||
"123456789",
|
||||
"1234567890",
|
||||
"0123",
|
||||
"01234",
|
||||
"012345",
|
||||
"0123456",
|
||||
"01234567",
|
||||
"012345678",
|
||||
"0123456789",
|
||||
"abcd",
|
||||
"abcde",
|
||||
"abcdef",
|
||||
"qwer",
|
||||
"qwerty",
|
||||
"asdf",
|
||||
"asdfg",
|
||||
"asdfgh",
|
||||
"aaaa",
|
||||
"bbbb",
|
||||
"cccc",
|
||||
"password",
|
||||
"letmein",
|
||||
}
|
||||
)
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Validation
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
class PasscodeValidationError(Exception):
|
||||
"""The proposed passcode failed validation. The endpoint surface
|
||||
maps this to HTTP 422 with the message intact."""
|
||||
|
||||
|
||||
def _validate(passcode: str) -> str:
|
||||
"""Return the normalized passcode (stripped) or raise.
|
||||
|
||||
Rules:
|
||||
* 4-20 characters after stripping leading/trailing whitespace.
|
||||
* Not on the small denylist of obvious patterns.
|
||||
|
||||
No character-class restriction beyond that — the spec says
|
||||
"numeric PIN or short alphanumeric"; we don't refuse other
|
||||
characters because the entropy isn't load-bearing (the per-account
|
||||
lockout is what carries the security weight, mirroring the OTC
|
||||
shape from v0.7.0).
|
||||
"""
|
||||
pc = (passcode or "").strip()
|
||||
if not pc:
|
||||
raise PasscodeValidationError("Passcode is required")
|
||||
if len(pc) < PASSCODE_MIN_LENGTH:
|
||||
raise PasscodeValidationError(
|
||||
f"Passcode must be at least {PASSCODE_MIN_LENGTH} characters"
|
||||
)
|
||||
if len(pc) > PASSCODE_MAX_LENGTH:
|
||||
raise PasscodeValidationError(
|
||||
f"Passcode must be at most {PASSCODE_MAX_LENGTH} characters"
|
||||
)
|
||||
if pc.lower() in PASSCODE_DENYLIST:
|
||||
raise PasscodeValidationError("Passcode is too common; pick something less obvious")
|
||||
return pc
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Hashing
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def _hash(passcode: str) -> str:
|
||||
return bcrypt.hashpw(passcode.encode("utf-8"), bcrypt.gensalt()).decode("ascii")
|
||||
|
||||
|
||||
def _check(passcode: str, passcode_hash: str) -> bool:
|
||||
try:
|
||||
return bcrypt.checkpw(passcode.encode("utf-8"), passcode_hash.encode("ascii"))
|
||||
except (ValueError, TypeError):
|
||||
return False
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Set / clear
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def set_passcode(user_id: int, passcode: str) -> None:
|
||||
"""Hash and store the passcode. Replaces any prior passcode on the
|
||||
same row; clears the failure counter and lockout (a user setting a
|
||||
fresh passcode is implicitly re-authenticating their account)."""
|
||||
pc = _validate(passcode)
|
||||
h = _hash(pc)
|
||||
db.conn().execute(
|
||||
"""
|
||||
UPDATE users
|
||||
SET passcode_hash = ?,
|
||||
passcode_set_at = datetime('now'),
|
||||
passcode_failed_attempts = 0,
|
||||
passcode_locked_until = NULL
|
||||
WHERE id = ?
|
||||
""",
|
||||
(h, user_id),
|
||||
)
|
||||
|
||||
|
||||
def clear_passcode(user_id: int) -> None:
|
||||
"""Remove the passcode. The user is back to OTC-only on next sign-in."""
|
||||
db.conn().execute(
|
||||
"""
|
||||
UPDATE users
|
||||
SET passcode_hash = NULL,
|
||||
passcode_set_at = NULL,
|
||||
passcode_failed_attempts = 0,
|
||||
passcode_locked_until = NULL
|
||||
WHERE id = ?
|
||||
""",
|
||||
(user_id,),
|
||||
)
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Check (status surface for the Login.jsx flow)
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
@dataclass
|
||||
class PasscodeStatus:
|
||||
"""The shape `/auth/passcode/check` returns.
|
||||
|
||||
`has_passcode` is the only signal the frontend needs to decide
|
||||
whether to show a passcode input or an OTC request step. We do
|
||||
not leak the hash, the set-at timestamp, or the lockout state —
|
||||
a probing client that wants to know "is this account locked
|
||||
out" can attempt a verify and read the 423.
|
||||
"""
|
||||
has_passcode: bool
|
||||
|
||||
|
||||
def passcode_status(email: str) -> PasscodeStatus:
|
||||
email = (email or "").strip()
|
||||
if not email or "@" not in email:
|
||||
return PasscodeStatus(has_passcode=False)
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_hash FROM users WHERE email = ? COLLATE NOCASE",
|
||||
(email,),
|
||||
).fetchone()
|
||||
if row is None:
|
||||
return PasscodeStatus(has_passcode=False)
|
||||
return PasscodeStatus(has_passcode=bool(row["passcode_hash"]))
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Verify
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
@dataclass
|
||||
class VerifyOutcome:
|
||||
"""Result of a `verify_passcode` call.
|
||||
|
||||
`reason` distinguishes the failure modes the endpoint surfaces as
|
||||
distinct HTTP shapes:
|
||||
* 'ok' — populated `user`, HTTP 200.
|
||||
* 'unknown' — no user with this email, HTTP 400 (generic).
|
||||
* 'no_passcode' — user exists but never set a passcode, HTTP 400
|
||||
(the frontend should fall back to OTC).
|
||||
* 'locked' — user is currently in the lockout window, HTTP
|
||||
423. `locked_until` carries the ISO-8601 stamp for the client.
|
||||
* 'wrong' — passcode didn't match. HTTP 400. If the failure
|
||||
crossed the lockout threshold the row is now locked; the
|
||||
endpoint surfaces this as a fresh `locked` response on the
|
||||
next attempt rather than collapsing the two states here.
|
||||
"""
|
||||
ok: bool
|
||||
user: SessionUser | None
|
||||
reason: str
|
||||
locked_until: str | None = None
|
||||
|
||||
|
||||
def verify_passcode(email: str, passcode: str) -> VerifyOutcome:
|
||||
email = (email or "").strip()
|
||||
passcode = (passcode or "").strip()
|
||||
if not email or not passcode:
|
||||
return VerifyOutcome(ok=False, user=None, reason="unknown")
|
||||
|
||||
row = db.conn().execute(
|
||||
"""
|
||||
SELECT id, gitea_id, gitea_login, email, display_name, avatar_url, role,
|
||||
passcode_hash, passcode_failed_attempts, passcode_locked_until
|
||||
FROM users
|
||||
WHERE email = ? COLLATE NOCASE
|
||||
""",
|
||||
(email,),
|
||||
).fetchone()
|
||||
if row is None:
|
||||
return VerifyOutcome(ok=False, user=None, reason="unknown")
|
||||
if not row["passcode_hash"]:
|
||||
return VerifyOutcome(ok=False, user=None, reason="no_passcode")
|
||||
|
||||
# Lockout check: if `passcode_locked_until` is populated and in the
|
||||
# future, the verify is refused without touching the hash. Once the
|
||||
# window has elapsed we let the verify proceed; the failed-attempts
|
||||
# counter is also reset so the user gets a fresh 5-attempt budget.
|
||||
locked_until = row["passcode_locked_until"]
|
||||
if locked_until:
|
||||
still_locked = db.conn().execute(
|
||||
"SELECT datetime(?) > datetime('now') AS still_locked",
|
||||
(locked_until,),
|
||||
).fetchone()["still_locked"]
|
||||
if still_locked:
|
||||
return VerifyOutcome(
|
||||
ok=False,
|
||||
user=None,
|
||||
reason="locked",
|
||||
locked_until=locked_until,
|
||||
)
|
||||
# Lockout expired — clear the counter so the next failure starts
|
||||
# from zero, and continue with the verify.
|
||||
db.conn().execute(
|
||||
"""
|
||||
UPDATE users
|
||||
SET passcode_failed_attempts = 0,
|
||||
passcode_locked_until = NULL
|
||||
WHERE id = ?
|
||||
""",
|
||||
(row["id"],),
|
||||
)
|
||||
|
||||
if _check(passcode, row["passcode_hash"]):
|
||||
# Success: clear the counter (a single success wipes the
|
||||
# accumulated failures — the threshold tracks *consecutive*
|
||||
# failures).
|
||||
db.conn().execute(
|
||||
"""
|
||||
UPDATE users
|
||||
SET passcode_failed_attempts = 0,
|
||||
passcode_locked_until = NULL,
|
||||
last_seen_at = datetime('now')
|
||||
WHERE id = ?
|
||||
""",
|
||||
(row["id"],),
|
||||
)
|
||||
return VerifyOutcome(
|
||||
ok=True,
|
||||
user=SessionUser(
|
||||
user_id=row["id"],
|
||||
gitea_id=row["gitea_id"] or 0,
|
||||
gitea_login=row["gitea_login"] or "",
|
||||
display_name=row["display_name"],
|
||||
email=row["email"] or email,
|
||||
avatar_url=row["avatar_url"] or "",
|
||||
role=row["role"],
|
||||
),
|
||||
reason="ok",
|
||||
)
|
||||
|
||||
# Failure: increment the counter. If this push crosses the
|
||||
# threshold, stamp the lockout. The next verify attempt against
|
||||
# the same row returns 423 with the `locked_until` stamp.
|
||||
next_count = (row["passcode_failed_attempts"] or 0) + 1
|
||||
if next_count >= LOCKOUT_AFTER_FAILED_ATTEMPTS:
|
||||
db.conn().execute(
|
||||
f"""
|
||||
UPDATE users
|
||||
SET passcode_failed_attempts = ?,
|
||||
passcode_locked_until = datetime('now', '+{LOCKOUT_DURATION_MINUTES} minutes')
|
||||
WHERE id = ?
|
||||
""",
|
||||
(next_count, row["id"]),
|
||||
)
|
||||
new_locked_until = db.conn().execute(
|
||||
"SELECT passcode_locked_until FROM users WHERE id = ?",
|
||||
(row["id"],),
|
||||
).fetchone()["passcode_locked_until"]
|
||||
return VerifyOutcome(
|
||||
ok=False,
|
||||
user=None,
|
||||
reason="locked",
|
||||
locked_until=new_locked_until,
|
||||
)
|
||||
db.conn().execute(
|
||||
"UPDATE users SET passcode_failed_attempts = ? WHERE id = ?",
|
||||
(next_count, row["id"]),
|
||||
)
|
||||
return VerifyOutcome(ok=False, user=None, reason="wrong")
|
||||
@@ -0,0 +1,148 @@
|
||||
"""§6.2 / v0.12.0 / roadmap item #10: CloudFlare Turnstile siteverify.
|
||||
|
||||
The OTC request endpoint (`/auth/otc/request`) is the abuse hot path
|
||||
of the auth surface since v0.7.0 — the per-email cooldown stops the
|
||||
trivial back-to-back loop, but it does not stop a distributed scraper
|
||||
that fans out across a large invitee list to harvest the "this email
|
||||
is admitted vs. this email is not" signal indirectly (timing
|
||||
differences, SMTP bounce-rate observation). v0.12.0 gates the request
|
||||
endpoint behind a one-step browser-side Turnstile challenge before the
|
||||
bcrypt hash + SMTP send.
|
||||
|
||||
Stateless: no DB writes, no schema change. The siteverify call to
|
||||
CloudFlare lives entirely in this module; the endpoint handler in
|
||||
`main.py` thin-wraps `verify_token`.
|
||||
|
||||
Tunables (read at call time so tests can monkeypatch):
|
||||
|
||||
* `CLOUDFLARE_TURNSTILE_SECRET` — the operator-provisioned secret
|
||||
key from the Turnstile dashboard. Lives in GCP Secret Manager in
|
||||
production; absent in tests (which monkeypatch the siteverify
|
||||
transport). When unset, the behavior depends on `TURNSTILE_REQUIRED`:
|
||||
- `TURNSTILE_REQUIRED=true` → fail closed (`misconfigured`).
|
||||
- `TURNSTILE_REQUIRED=false` (default) → skip verification entirely
|
||||
and admit the request. This is the dev/test path and the
|
||||
"operator hasn't wired the secret yet" path; production
|
||||
deployments **should** set `TURNSTILE_REQUIRED=true` once the
|
||||
secret is in place so a regression in the secret wiring fails
|
||||
loudly instead of silently disabling abuse defense.
|
||||
|
||||
* `TURNSTILE_REQUIRED` — `true` / `false` (default `false`).
|
||||
When `false` and the secret is absent, the gate is open. When
|
||||
`true` and the secret is absent, the endpoint refuses with a
|
||||
misconfigured-auth shape rather than silently letting requests
|
||||
through.
|
||||
|
||||
* `TURNSTILE_SITEVERIFY_URL` — points at the real CloudFlare
|
||||
endpoint by default. Override in tests to redirect at a mock
|
||||
URL when `httpx.MockTransport` isn't ergonomic for the case.
|
||||
|
||||
The siteverify contract is documented at
|
||||
https://developers.cloudflare.com/turnstile/get-started/server-side-validation/.
|
||||
We POST `secret` + `response` (and optionally `remoteip`) as form
|
||||
fields and read back `{"success": true|false, ...}`. Any network /
|
||||
parse failure on the siteverify call is treated as a verification
|
||||
failure (`network`) — the abuse path is to skip the challenge, so
|
||||
"can't reach CloudFlare" defaults to "refuse the request" when
|
||||
`TURNSTILE_REQUIRED=true`, and "admit" when `TURNSTILE_REQUIRED=false`.
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
import logging
|
||||
import os
|
||||
from dataclasses import dataclass
|
||||
|
||||
import httpx
|
||||
|
||||
log = logging.getLogger(__name__)
|
||||
|
||||
|
||||
SITEVERIFY_URL = "https://challenges.cloudflare.com/turnstile/v0/siteverify"
|
||||
|
||||
|
||||
def _secret() -> str:
|
||||
return os.environ.get("CLOUDFLARE_TURNSTILE_SECRET", "").strip()
|
||||
|
||||
|
||||
def _required() -> bool:
|
||||
raw = os.environ.get("TURNSTILE_REQUIRED", "").strip().lower()
|
||||
return raw in ("1", "true", "yes", "on")
|
||||
|
||||
|
||||
def _siteverify_url() -> str:
|
||||
return os.environ.get("TURNSTILE_SITEVERIFY_URL", "").strip() or SITEVERIFY_URL
|
||||
|
||||
|
||||
@dataclass
|
||||
class VerifyOutcome:
|
||||
"""Result of a Turnstile siteverify call.
|
||||
|
||||
`ok`: the request **may proceed**. True both for "siteverify said
|
||||
success" and for "no secret configured AND not required" (the
|
||||
dev/test soft-fail path).
|
||||
|
||||
`reason`: one of
|
||||
* 'ok' — siteverify returned success.
|
||||
* 'skipped' — no secret configured, TURNSTILE_REQUIRED=false.
|
||||
The gate is open; the endpoint admits the request.
|
||||
* 'misconfigured' — TURNSTILE_REQUIRED=true but no secret in env.
|
||||
The endpoint fails closed with 500.
|
||||
* 'missing-token' — the client did not send a token at all and
|
||||
verification is required.
|
||||
* 'failed' — siteverify returned success=false. The
|
||||
endpoint refuses with 400.
|
||||
* 'network' — siteverify call raised. Treated as a failure
|
||||
under TURNSTILE_REQUIRED=true.
|
||||
"""
|
||||
ok: bool
|
||||
reason: str
|
||||
|
||||
|
||||
def verify_token(token: str | None, *, client_ip: str | None = None) -> VerifyOutcome:
|
||||
"""Validate a Turnstile token against CloudFlare's siteverify endpoint.
|
||||
|
||||
Returns a VerifyOutcome describing whether the calling endpoint
|
||||
should proceed. The endpoint maps `ok=False` to an HTTP status per
|
||||
the `reason`:
|
||||
|
||||
* 'misconfigured' → 500 "auth misconfigured"
|
||||
* 'missing-token' / 'failed' / 'network' → 400 "verification failed"
|
||||
|
||||
Tests monkeypatch `httpx.post` (or set `TURNSTILE_SITEVERIFY_URL`
|
||||
+ a MockTransport client) to avoid touching the real CloudFlare
|
||||
endpoint. No real keys are ever embedded in tests.
|
||||
"""
|
||||
secret = _secret()
|
||||
required = _required()
|
||||
|
||||
if not secret:
|
||||
if required:
|
||||
log.warning("Turnstile required but CLOUDFLARE_TURNSTILE_SECRET is unset; failing closed")
|
||||
return VerifyOutcome(ok=False, reason="misconfigured")
|
||||
# Dev/test/soft-fail path: no secret, not required → gate is open.
|
||||
return VerifyOutcome(ok=True, reason="skipped")
|
||||
|
||||
if not token or not token.strip():
|
||||
# Secret is set, so verification is in force. A missing token
|
||||
# is a hard refuse — the frontend should have rendered the
|
||||
# widget and collected one.
|
||||
return VerifyOutcome(ok=False, reason="missing-token")
|
||||
|
||||
data = {"secret": secret, "response": token.strip()}
|
||||
if client_ip:
|
||||
data["remoteip"] = client_ip
|
||||
|
||||
try:
|
||||
response = httpx.post(_siteverify_url(), data=data, timeout=10.0)
|
||||
payload = response.json()
|
||||
except Exception as exc: # network, JSON parse, etc.
|
||||
log.warning("Turnstile siteverify call failed: %s", exc)
|
||||
return VerifyOutcome(ok=False, reason="network")
|
||||
|
||||
if payload.get("success") is True:
|
||||
return VerifyOutcome(ok=True, reason="ok")
|
||||
|
||||
# `error-codes` is a list of strings on failure; we log the codes
|
||||
# for the operator without surfacing them to the client.
|
||||
log.info("Turnstile siteverify rejected token: %s", payload.get("error-codes"))
|
||||
return VerifyOutcome(ok=False, reason="failed")
|
||||
@@ -0,0 +1,52 @@
|
||||
-- §6.2 / v0.10.0: user-set passcodes after OTC (roadmap item #8).
|
||||
--
|
||||
-- After a successful OTC sign-in, a contributor may set a passcode
|
||||
-- (numeric PIN or short alphanumeric). Subsequent sign-ins on the same
|
||||
-- account can use email + passcode instead of email + OTC. OTC remains
|
||||
-- the structural fallback — a forgotten passcode is recovered by
|
||||
-- requesting a fresh OTC and signing in via that path. Per-account
|
||||
-- lockout after 5 consecutive verify failures redirects the user to
|
||||
-- the OTC path for 15 minutes; the OTC path itself is unaffected by
|
||||
-- the passcode lockout (a locked-out user can still receive a fresh
|
||||
-- code and sign in).
|
||||
--
|
||||
-- The columns are additive to the `users` table from `012_otc.sql`.
|
||||
-- v0.8.0's `permission_state` column (roadmap item #6) lands in the
|
||||
-- driver's integration order ahead of this migration; we do not touch
|
||||
-- that column here. v0.7.0's nullable-`gitea_id`/`gitea_login` shape
|
||||
-- is preserved verbatim.
|
||||
--
|
||||
-- Storage shape:
|
||||
--
|
||||
-- * `passcode_hash` (nullable) — bcrypt hash of the passcode.
|
||||
-- NULL means "no passcode set"; the user is OTC-only.
|
||||
-- * `passcode_set_at` (nullable) — timestamp of the most recent
|
||||
-- `passcode/set` call. Updated when a passcode is set or
|
||||
-- replaced; cleared when the passcode is removed.
|
||||
-- * `passcode_failed_attempts` — count of consecutive failed
|
||||
-- verify attempts since the last successful verify (or since
|
||||
-- the lockout cleared). Resets to 0 on success and on lockout
|
||||
-- expiry. Defaults to 0 so existing rows post-migration are
|
||||
-- not implicitly half-locked.
|
||||
-- * `passcode_locked_until` (nullable) — if populated and the
|
||||
-- timestamp is in the future, passcode verify is refused with
|
||||
-- HTTP 423. Cleared on successful verify after the window
|
||||
-- expires, or by the operator via direct DB intervention if
|
||||
-- ever needed (no admin endpoint surfaces this in v1).
|
||||
--
|
||||
-- v0.10.0 introduces no new env vars. The lockout window (5 attempts,
|
||||
-- 15 minutes) is hard-coded in `backend/app/passcode.py`; raising or
|
||||
-- lowering it is a future-§19.2 candidate. Passcode hashing reuses
|
||||
-- the bcrypt dependency added in v0.7.0 for OTC; no new secret is
|
||||
-- required (the existing `SECRET_KEY` continues to sign sessions).
|
||||
--
|
||||
-- Note on SQLite: ALTER TABLE ... ADD COLUMN is supported, so this
|
||||
-- migration does not need the rebuild dance that `012_otc.sql`
|
||||
-- required. The runner wraps each file in a single BEGIN/COMMIT
|
||||
-- block — see `backend/app/db.py` — so either every ADD COLUMN
|
||||
-- here lands or none do.
|
||||
|
||||
ALTER TABLE users ADD COLUMN passcode_hash TEXT;
|
||||
ALTER TABLE users ADD COLUMN passcode_set_at TEXT;
|
||||
ALTER TABLE users ADD COLUMN passcode_failed_attempts INTEGER NOT NULL DEFAULT 0;
|
||||
ALTER TABLE users ADD COLUMN passcode_locked_until TEXT;
|
||||
@@ -0,0 +1,532 @@
|
||||
"""End-to-end integration tests for the v0.10.0 user-set passcode
|
||||
vertical (§6.2, roadmap item #8).
|
||||
|
||||
After a successful OTC sign-in the user can set a passcode and use
|
||||
email + passcode for subsequent sign-ins. OTC remains the structural
|
||||
fallback — these tests prove:
|
||||
|
||||
* `/auth/passcode/set` requires an active session.
|
||||
* `/auth/passcode/check` returns `has_passcode` without leaking the
|
||||
hash, the set-at stamp, or the lockout state.
|
||||
* Happy path: OTC sign-in → set passcode → sign out → email +
|
||||
passcode signs in (no OTC roundtrip).
|
||||
* Wrong passcode increments the failure counter without locking.
|
||||
* Five consecutive failures lock the passcode path (HTTP 423) and
|
||||
persist `passcode_locked_until` on the user row.
|
||||
* The lockout expires after `passcode_locked_until`; a verify
|
||||
attempt past the window succeeds again and clears the counter.
|
||||
* The OTC path is unaffected by the passcode lockout — a user
|
||||
whose passcode is locked can still request and verify a fresh
|
||||
OTC to sign in.
|
||||
* Clearing the passcode wipes the hash; subsequent verify refuses
|
||||
with the no-passcode failure shape.
|
||||
* Setting a new passcode replaces the prior one (and resets the
|
||||
failure counter / lockout state).
|
||||
* `passcode_set_at` updates on every set call.
|
||||
* The validation denylist refuses obvious patterns (e.g. `0000`,
|
||||
`1234`).
|
||||
* Passcode length is enforced (4-20).
|
||||
|
||||
The fakes from `test_propose_vertical` give us a working app harness.
|
||||
The OTC envelope buffer from `test_otc_vertical` is reused for the
|
||||
OTC roundtrips this suite needs.
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
import pytest
|
||||
|
||||
from test_propose_vertical import ( # noqa: F401
|
||||
FakeGitea,
|
||||
app_with_fake_gitea,
|
||||
provision_user_row,
|
||||
tmp_env,
|
||||
)
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Helpers — mirror the OTC suite's outbound-buffer helpers.
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def _reset_outbound():
|
||||
from app import email as email_mod
|
||||
email_mod.reset_sent_envelopes()
|
||||
|
||||
|
||||
def _outbound_otc_codes(to_address: str | None = None) -> list[str]:
|
||||
from app import email as email_mod
|
||||
out = []
|
||||
for env in email_mod.sent_envelopes():
|
||||
if env.get("kind") != "otc":
|
||||
continue
|
||||
if to_address is not None and env["to"] != to_address:
|
||||
continue
|
||||
for line in env["body"].splitlines():
|
||||
tok = line.strip()
|
||||
if tok.isdigit() and len(tok) == 6:
|
||||
out.append(tok)
|
||||
break
|
||||
return out
|
||||
|
||||
|
||||
def _sign_in_via_otc(client, email: str) -> None:
|
||||
"""Run an OTC request+verify so the client carries an authenticated
|
||||
session. The cooldown is irrelevant on a fresh email; we don't
|
||||
need to drop it."""
|
||||
r = client.post("/auth/otc/request", json={"email": email})
|
||||
assert r.status_code == 200, r.text
|
||||
code = _outbound_otc_codes(email)[-1]
|
||||
r = client.post("/auth/otc/verify", json={"email": email, "code": code})
|
||||
assert r.status_code == 200, r.text
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Set passcode — auth-required, happy path
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_set_passcode_requires_session(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
r = client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
assert r.status_code == 401
|
||||
|
||||
|
||||
def test_set_passcode_after_otc_landing_persists_hash(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
from app import db
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "alice@example.com")
|
||||
|
||||
r = client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
assert r.status_code == 200, r.text
|
||||
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_hash, passcode_set_at FROM users WHERE email = ? COLLATE NOCASE",
|
||||
("alice@example.com",),
|
||||
).fetchone()
|
||||
assert row is not None
|
||||
assert row["passcode_hash"] is not None
|
||||
# Not the plaintext.
|
||||
assert row["passcode_hash"] != "secret123"
|
||||
assert row["passcode_set_at"] is not None
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Check endpoint — leak-free shape
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_check_endpoint_returns_false_for_unknown_email(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
r = client.get("/auth/passcode/check", params={"email": "nobody@example.com"})
|
||||
assert r.status_code == 200
|
||||
assert r.json() == {"has_passcode": False}
|
||||
|
||||
|
||||
def test_check_endpoint_returns_false_for_user_without_passcode(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "bob@example.com")
|
||||
|
||||
r = client.get("/auth/passcode/check", params={"email": "bob@example.com"})
|
||||
assert r.status_code == 200
|
||||
assert r.json() == {"has_passcode": False}
|
||||
|
||||
|
||||
def test_check_endpoint_returns_true_after_set(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "carol@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "letmein9"})
|
||||
|
||||
# Drop the session so the check is read in the anonymous shape.
|
||||
client.cookies.clear()
|
||||
r = client.get("/auth/passcode/check", params={"email": "carol@example.com"})
|
||||
assert r.status_code == 200
|
||||
assert r.json() == {"has_passcode": True}
|
||||
# The response carries ONLY the boolean — no hash, no stamp.
|
||||
assert set(r.json().keys()) == {"has_passcode"}
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Verify path — happy path
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_verify_passcode_signs_in_user(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "dave@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
client.cookies.clear()
|
||||
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "dave@example.com", "passcode": "secret123"},
|
||||
)
|
||||
assert r.status_code == 200, r.text
|
||||
me = client.get("/api/auth/me").json()
|
||||
assert me["authenticated"] is True
|
||||
assert me["user"]["email"] == "dave@example.com"
|
||||
assert me["user"]["has_passcode"] is True
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Verify path — failure modes
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_verify_passcode_wrong_increments_counter_without_locking(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
from app import db
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "erin@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
client.cookies.clear()
|
||||
|
||||
# Three bad attempts — under the lockout threshold.
|
||||
for _ in range(3):
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "erin@example.com", "passcode": "wrongwrong"},
|
||||
)
|
||||
assert r.status_code == 400
|
||||
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_failed_attempts, passcode_locked_until FROM users WHERE email = ?",
|
||||
("erin@example.com",),
|
||||
).fetchone()
|
||||
assert row["passcode_failed_attempts"] == 3
|
||||
assert row["passcode_locked_until"] is None
|
||||
|
||||
|
||||
def test_verify_passcode_locks_after_five_failures(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
from app import db
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "frank@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
client.cookies.clear()
|
||||
|
||||
# Five bad attempts — the last crosses the threshold and the
|
||||
# response shape flips to 423.
|
||||
statuses = []
|
||||
for _ in range(5):
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "frank@example.com", "passcode": "wrongwrong"},
|
||||
)
|
||||
statuses.append(r.status_code)
|
||||
# First four are 400, the fifth (threshold-crossing) is 423.
|
||||
assert statuses == [400, 400, 400, 400, 423]
|
||||
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_failed_attempts, passcode_locked_until FROM users WHERE email = ?",
|
||||
("frank@example.com",),
|
||||
).fetchone()
|
||||
assert row["passcode_failed_attempts"] >= 5
|
||||
assert row["passcode_locked_until"] is not None
|
||||
|
||||
# Sixth attempt — still locked, still 423, even with the correct
|
||||
# passcode (lockout overrides the verify).
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "frank@example.com", "passcode": "secret123"},
|
||||
)
|
||||
assert r.status_code == 423
|
||||
|
||||
|
||||
def test_verify_passcode_lockout_expires(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
from app import db
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "gina@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
client.cookies.clear()
|
||||
|
||||
for _ in range(5):
|
||||
client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "gina@example.com", "passcode": "wrongwrong"},
|
||||
)
|
||||
|
||||
# Backdate the lockout to the past so the next attempt clears it.
|
||||
db.conn().execute(
|
||||
"""
|
||||
UPDATE users
|
||||
SET passcode_locked_until = datetime('now', '-1 minute')
|
||||
WHERE email = ?
|
||||
""",
|
||||
("gina@example.com",),
|
||||
)
|
||||
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "gina@example.com", "passcode": "secret123"},
|
||||
)
|
||||
assert r.status_code == 200, r.text
|
||||
|
||||
# Lockout cleared, counter reset.
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_failed_attempts, passcode_locked_until FROM users WHERE email = ?",
|
||||
("gina@example.com",),
|
||||
).fetchone()
|
||||
assert row["passcode_failed_attempts"] == 0
|
||||
assert row["passcode_locked_until"] is None
|
||||
|
||||
|
||||
def test_otc_path_unaffected_by_passcode_lockout(app_with_fake_gitea, monkeypatch):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
# Drop the OTC cooldown so the second request lands without a 429.
|
||||
# The cooldown is re-read from env on every `request_code` call so
|
||||
# this takes effect mid-process.
|
||||
monkeypatch.setenv("OTC_REQUEST_COOLDOWN_SECONDS", "0")
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "harvey@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
client.cookies.clear()
|
||||
|
||||
# Lock the passcode path.
|
||||
for _ in range(5):
|
||||
client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "harvey@example.com", "passcode": "wrongwrong"},
|
||||
)
|
||||
|
||||
# The OTC path is unaffected by the passcode lockout: the user
|
||||
# can still request and verify a fresh code to sign in.
|
||||
r = client.post("/auth/otc/request", json={"email": "harvey@example.com"})
|
||||
assert r.status_code == 200
|
||||
code = _outbound_otc_codes("harvey@example.com")[-1]
|
||||
r = client.post("/auth/otc/verify", json={"email": "harvey@example.com", "code": code})
|
||||
assert r.status_code == 200
|
||||
|
||||
# The user is now signed in via OTC even though the passcode
|
||||
# path is locked. The /api/auth/me payload reflects this.
|
||||
me = client.get("/api/auth/me").json()
|
||||
assert me["authenticated"] is True
|
||||
assert me["user"]["email"] == "harvey@example.com"
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Clear + replace
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_clear_passcode_wipes_the_hash(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
from app import db
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "ivy@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
|
||||
r = client.delete("/auth/passcode")
|
||||
assert r.status_code == 200
|
||||
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_hash, passcode_set_at FROM users WHERE email = ?",
|
||||
("ivy@example.com",),
|
||||
).fetchone()
|
||||
assert row["passcode_hash"] is None
|
||||
assert row["passcode_set_at"] is None
|
||||
|
||||
# Verify against the cleared passcode refuses (no-passcode shape
|
||||
# collapses to a generic 400).
|
||||
client.cookies.clear()
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "ivy@example.com", "passcode": "secret123"},
|
||||
)
|
||||
assert r.status_code == 400
|
||||
|
||||
|
||||
def test_setting_new_passcode_replaces_old(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "jane@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
# Replace.
|
||||
r = client.post("/auth/passcode/set", json={"passcode": "newsecret9"})
|
||||
assert r.status_code == 200
|
||||
|
||||
client.cookies.clear()
|
||||
|
||||
# Old passcode refuses.
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "jane@example.com", "passcode": "secret123"},
|
||||
)
|
||||
assert r.status_code == 400
|
||||
|
||||
# New passcode signs in.
|
||||
r = client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "jane@example.com", "passcode": "newsecret9"},
|
||||
)
|
||||
assert r.status_code == 200
|
||||
|
||||
|
||||
def test_setting_new_passcode_resets_lockout(app_with_fake_gitea, monkeypatch):
|
||||
from fastapi.testclient import TestClient
|
||||
from app import db
|
||||
|
||||
monkeypatch.setenv("OTC_REQUEST_COOLDOWN_SECONDS", "0")
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "kate@example.com")
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
|
||||
# Lock the passcode path with bad attempts (drop session first).
|
||||
client.cookies.clear()
|
||||
for _ in range(5):
|
||||
client.post(
|
||||
"/auth/passcode/verify",
|
||||
json={"email": "kate@example.com", "passcode": "wrongwrong"},
|
||||
)
|
||||
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_locked_until FROM users WHERE email = ?",
|
||||
("kate@example.com",),
|
||||
).fetchone()
|
||||
assert row["passcode_locked_until"] is not None
|
||||
|
||||
# Sign back in via OTC and reset the passcode.
|
||||
r = client.post("/auth/otc/request", json={"email": "kate@example.com"})
|
||||
assert r.status_code == 200
|
||||
code = _outbound_otc_codes("kate@example.com")[-1]
|
||||
r = client.post("/auth/otc/verify", json={"email": "kate@example.com", "code": code})
|
||||
assert r.status_code == 200
|
||||
|
||||
r = client.post("/auth/passcode/set", json={"passcode": "freshcode9"})
|
||||
assert r.status_code == 200
|
||||
|
||||
# Lockout cleared on set.
|
||||
row = db.conn().execute(
|
||||
"SELECT passcode_locked_until, passcode_failed_attempts FROM users WHERE email = ?",
|
||||
("kate@example.com",),
|
||||
).fetchone()
|
||||
assert row["passcode_locked_until"] is None
|
||||
assert row["passcode_failed_attempts"] == 0
|
||||
|
||||
|
||||
def test_passcode_set_at_updates_on_each_set(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
from app import db
|
||||
import time
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "luke@example.com")
|
||||
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
first_stamp = db.conn().execute(
|
||||
"SELECT passcode_set_at FROM users WHERE email = ?",
|
||||
("luke@example.com",),
|
||||
).fetchone()["passcode_set_at"]
|
||||
assert first_stamp is not None
|
||||
|
||||
# SQLite's datetime('now') has second precision; sleep so the
|
||||
# stamp visibly advances on the next set.
|
||||
time.sleep(1.1)
|
||||
|
||||
client.post("/auth/passcode/set", json={"passcode": "newcode99"})
|
||||
second_stamp = db.conn().execute(
|
||||
"SELECT passcode_set_at FROM users WHERE email = ?",
|
||||
("luke@example.com",),
|
||||
).fetchone()["passcode_set_at"]
|
||||
assert second_stamp is not None
|
||||
assert second_stamp >= first_stamp
|
||||
# Lexicographic compare on ISO-8601 datetime strings works for
|
||||
# the SQLite shape.
|
||||
assert second_stamp > first_stamp
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Validation
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_set_passcode_refuses_too_short(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "mia@example.com")
|
||||
r = client.post("/auth/passcode/set", json={"passcode": "abc"})
|
||||
assert r.status_code == 422
|
||||
|
||||
|
||||
def test_set_passcode_refuses_denylist_pattern(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "nick@example.com")
|
||||
for bad in ["0000", "1234", "aaaa", "qwerty", "password"]:
|
||||
r = client.post("/auth/passcode/set", json={"passcode": bad})
|
||||
assert r.status_code == 422, f"expected 422 for {bad!r}, got {r.status_code}"
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Auth me payload
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_auth_me_carries_has_passcode_flag(app_with_fake_gitea):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
_sign_in_via_otc(client, "olga@example.com")
|
||||
|
||||
me = client.get("/api/auth/me").json()
|
||||
assert me["user"]["has_passcode"] is False
|
||||
assert me["user"]["passcode_set_at"] is None
|
||||
|
||||
client.post("/auth/passcode/set", json={"passcode": "secret123"})
|
||||
me = client.get("/api/auth/me").json()
|
||||
assert me["user"]["has_passcode"] is True
|
||||
assert me["user"]["passcode_set_at"] is not None
|
||||
@@ -0,0 +1,220 @@
|
||||
"""End-to-end integration tests for the v0.12.0 CloudFlare Turnstile
|
||||
gate on `/auth/otc/request` (§6.2 / roadmap item #10).
|
||||
|
||||
The release gates the OTC request endpoint behind a one-step
|
||||
browser-side Turnstile challenge before the bcrypt hash + SMTP send.
|
||||
The tests prove:
|
||||
|
||||
* Happy path: with the secret set, a valid token admits the request
|
||||
and the OTC envelope lands.
|
||||
* Failure path: with the secret set, a token siteverify rejects
|
||||
refuses the request with 400 and produces no envelope.
|
||||
* Missing-token: with the secret set, a request without a token
|
||||
refuses with 400.
|
||||
* Missing-secret-soft: with the secret unset AND
|
||||
`TURNSTILE_REQUIRED=false` (the v0.12.0 default), the request
|
||||
admits — this is the dev / "operator hasn't wired it yet" path.
|
||||
* Missing-secret-hard: with the secret unset AND
|
||||
`TURNSTILE_REQUIRED=true`, the request refuses with 500
|
||||
"auth misconfigured" — the production fail-closed path once
|
||||
the operator has flipped the policy.
|
||||
|
||||
The Turnstile siteverify call is mocked at the `httpx.post` boundary
|
||||
inside `app.turnstile` so no real keys are needed and no real
|
||||
CloudFlare call is made. The Gitea fakes from `test_propose_vertical`
|
||||
remain in scope so the rest of the app boots cleanly.
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
from types import SimpleNamespace
|
||||
|
||||
import pytest
|
||||
|
||||
from test_propose_vertical import ( # noqa: F401
|
||||
FakeGitea,
|
||||
app_with_fake_gitea,
|
||||
tmp_env,
|
||||
)
|
||||
|
||||
|
||||
def _reset_outbound():
|
||||
from app import email as email_mod
|
||||
email_mod.reset_sent_envelopes()
|
||||
|
||||
|
||||
def _outbound_otc_envelopes(to_address: str | None = None) -> list[dict]:
|
||||
from app import email as email_mod
|
||||
out = []
|
||||
for env in email_mod.sent_envelopes():
|
||||
if env.get("kind") != "otc":
|
||||
continue
|
||||
if to_address is not None and env["to"] != to_address:
|
||||
continue
|
||||
out.append(env)
|
||||
return out
|
||||
|
||||
|
||||
def _patch_siteverify(monkeypatch, *, success: bool, error_codes: list[str] | None = None):
|
||||
"""Replace `httpx.post` inside `app.turnstile` with a stub that
|
||||
returns the requested success shape. The stub does not touch the
|
||||
real CloudFlare endpoint and never sees a real secret.
|
||||
"""
|
||||
captured = {}
|
||||
|
||||
def fake_post(url, *, data=None, timeout=None, **kwargs):
|
||||
captured["url"] = url
|
||||
captured["data"] = data
|
||||
body = {"success": bool(success)}
|
||||
if error_codes is not None:
|
||||
body["error-codes"] = error_codes
|
||||
return SimpleNamespace(json=lambda: body)
|
||||
|
||||
from app import turnstile as turnstile_mod
|
||||
monkeypatch.setattr(turnstile_mod.httpx, "post", fake_post)
|
||||
return captured
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Happy path: secret set, token valid → admit + OTC envelope lands
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_otc_request_admits_when_turnstile_token_is_valid(app_with_fake_gitea, monkeypatch):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
monkeypatch.setenv("CLOUDFLARE_TURNSTILE_SECRET", "test-secret-not-real")
|
||||
monkeypatch.setenv("TURNSTILE_REQUIRED", "true")
|
||||
captured = _patch_siteverify(monkeypatch, success=True)
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
r = client.post(
|
||||
"/auth/otc/request",
|
||||
json={"email": "alice@example.com", "turnstile_token": "fake-token-abc"},
|
||||
)
|
||||
assert r.status_code == 200, r.text
|
||||
# The siteverify call was made with the secret + the token we sent.
|
||||
assert captured["data"]["secret"] == "test-secret-not-real"
|
||||
assert captured["data"]["response"] == "fake-token-abc"
|
||||
# And the OTC dispatch ran — exactly one envelope to the address.
|
||||
envs = _outbound_otc_envelopes("alice@example.com")
|
||||
assert len(envs) == 1
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Failure path: secret set, siteverify says success=false → 400 + no envelope
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_otc_request_refuses_when_turnstile_siteverify_fails(app_with_fake_gitea, monkeypatch):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
monkeypatch.setenv("CLOUDFLARE_TURNSTILE_SECRET", "test-secret-not-real")
|
||||
monkeypatch.setenv("TURNSTILE_REQUIRED", "true")
|
||||
_patch_siteverify(monkeypatch, success=False, error_codes=["invalid-input-response"])
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
r = client.post(
|
||||
"/auth/otc/request",
|
||||
json={"email": "alice@example.com", "turnstile_token": "fake-bad-token"},
|
||||
)
|
||||
assert r.status_code == 400, r.text
|
||||
# The OTC bcrypt + SMTP path did not run — no envelope was buffered.
|
||||
assert _outbound_otc_envelopes("alice@example.com") == []
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Missing-token: secret set, no token → 400 + no envelope
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_otc_request_refuses_when_turnstile_token_is_missing(app_with_fake_gitea, monkeypatch):
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
monkeypatch.setenv("CLOUDFLARE_TURNSTILE_SECRET", "test-secret-not-real")
|
||||
monkeypatch.setenv("TURNSTILE_REQUIRED", "true")
|
||||
# Even though we patch httpx.post, the missing-token check fires
|
||||
# before the siteverify call — so the patch is here only as a
|
||||
# safety net in case the implementation regresses to making the
|
||||
# network call anyway.
|
||||
_patch_siteverify(monkeypatch, success=False)
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
r = client.post(
|
||||
"/auth/otc/request",
|
||||
json={"email": "alice@example.com"}, # no turnstile_token field at all
|
||||
)
|
||||
assert r.status_code == 400, r.text
|
||||
assert _outbound_otc_envelopes("alice@example.com") == []
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Missing-secret-soft: no secret, TURNSTILE_REQUIRED=false (default) → admit
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_otc_request_admits_when_secret_unset_and_not_required(app_with_fake_gitea, monkeypatch):
|
||||
"""v0.12.0 default: the operator has not yet wired the Turnstile
|
||||
secret and has not enabled `TURNSTILE_REQUIRED`. The gate stays
|
||||
open — this is the dev / test / pre-rollout path. Once the
|
||||
operator confirms the secret is in place and flips
|
||||
`TURNSTILE_REQUIRED=true`, missing-secret becomes fail-closed
|
||||
(covered in test_otc_request_refuses_when_required_but_secret_unset).
|
||||
"""
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
monkeypatch.delenv("CLOUDFLARE_TURNSTILE_SECRET", raising=False)
|
||||
monkeypatch.delenv("TURNSTILE_REQUIRED", raising=False)
|
||||
# The httpx.post inside turnstile must not be called in this path —
|
||||
# patch it to a sentinel that explodes if it ever runs.
|
||||
from app import turnstile as turnstile_mod
|
||||
|
||||
def must_not_be_called(*a, **kw):
|
||||
raise AssertionError("siteverify should not run when no secret is configured")
|
||||
|
||||
monkeypatch.setattr(turnstile_mod.httpx, "post", must_not_be_called)
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
r = client.post(
|
||||
"/auth/otc/request",
|
||||
json={"email": "alice@example.com"},
|
||||
)
|
||||
assert r.status_code == 200, r.text
|
||||
# The OTC path ran end-to-end — one envelope to the address.
|
||||
assert len(_outbound_otc_envelopes("alice@example.com")) == 1
|
||||
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Missing-secret-hard: no secret, TURNSTILE_REQUIRED=true → 500 "misconfigured"
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
|
||||
def test_otc_request_refuses_when_required_but_secret_unset(app_with_fake_gitea, monkeypatch):
|
||||
"""Once the operator has flipped `TURNSTILE_REQUIRED=true` to lock
|
||||
down production, a missing secret stops being a soft-fail and
|
||||
becomes a fail-closed 500. This is the regression-detection shape
|
||||
the §20.4 upgrade-steps MAY block calls out — flip the flag once
|
||||
the secret is wired so a future config drift fails loudly instead
|
||||
of silently disabling abuse defense.
|
||||
"""
|
||||
from fastapi.testclient import TestClient
|
||||
|
||||
monkeypatch.delenv("CLOUDFLARE_TURNSTILE_SECRET", raising=False)
|
||||
monkeypatch.setenv("TURNSTILE_REQUIRED", "true")
|
||||
|
||||
app, _fake = app_with_fake_gitea
|
||||
with TestClient(app) as client:
|
||||
_reset_outbound()
|
||||
r = client.post(
|
||||
"/auth/otc/request",
|
||||
json={"email": "alice@example.com", "turnstile_token": "doesnt-matter"},
|
||||
)
|
||||
assert r.status_code == 500, r.text
|
||||
assert _outbound_otc_envelopes("alice@example.com") == []
|
||||
@@ -49,3 +49,16 @@ VITE_PRIVACY_POLICY_URL=
|
||||
# Examples:
|
||||
# VITE_COOKIES_POLICY_URL=https://wiggleverse.org/cookies
|
||||
VITE_COOKIES_POLICY_URL=
|
||||
|
||||
# v0.12.0 / roadmap item #10: CloudFlare Turnstile site key (public).
|
||||
# Provision a Turnstile site at dash.cloudflare.com → Turnstile → Add
|
||||
# site. The site key (this var) is embedded into the frontend bundle at
|
||||
# build time and rendered by the Turnstile widget on the /login email-
|
||||
# entry step. The secret key (private) lives in the backend env as
|
||||
# CLOUDFLARE_TURNSTILE_SECRET — see backend/.env.example. Leave unset
|
||||
# in dev to skip the widget; the backend's TURNSTILE_REQUIRED policy
|
||||
# decides what happens to a tokenless request.
|
||||
#
|
||||
# Examples:
|
||||
# VITE_TURNSTILE_SITE_KEY=0x4AAAAAAA...
|
||||
VITE_TURNSTILE_SITE_KEY=
|
||||
|
||||
Generated
+2
-2
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"name": "rfc-app-frontend",
|
||||
"version": "0.8.0",
|
||||
"version": "0.12.0",
|
||||
"lockfileVersion": 3,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"name": "rfc-app-frontend",
|
||||
"version": "0.8.0",
|
||||
"version": "0.12.0",
|
||||
"dependencies": {
|
||||
"@codemirror/commands": "^6.10.3",
|
||||
"@codemirror/lang-markdown": "^6.5.0",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "rfc-app-frontend",
|
||||
"private": true,
|
||||
"version": "0.8.0",
|
||||
"version": "0.12.0",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
|
||||
@@ -11,6 +11,7 @@ import Landing from './components/Landing.jsx'
|
||||
import Login from './components/Login.jsx'
|
||||
import BetaPending from './components/BetaPending.jsx'
|
||||
import Philosophy from './components/Philosophy.jsx'
|
||||
import Docs from './components/Docs.jsx'
|
||||
import NotificationSettings from './components/NotificationSettings.jsx'
|
||||
import Admin from './components/Admin.jsx'
|
||||
import ToastHost, { showToast } from './components/ToastHost.jsx'
|
||||
@@ -111,6 +112,9 @@ export default function App() {
|
||||
<Link to="/philosophy" className="header-about" title="Why this exists (§14)">
|
||||
About
|
||||
</Link>
|
||||
<Link to="/docs" className="header-about" title="User guide">
|
||||
Docs
|
||||
</Link>
|
||||
{viewer && (
|
||||
<Link to="/settings/notifications" className="header-settings" title="Notification settings (§15)">
|
||||
Settings
|
||||
@@ -153,6 +157,7 @@ export default function App() {
|
||||
<Route path="/login" element={<Login />} />
|
||||
<Route path="/beta-pending" element={<BetaPending viewer={viewer} />} />
|
||||
<Route path="/philosophy" element={<PhilosophyWithSidebar viewer={viewer} />} />
|
||||
<Route path="/docs" element={<DocsWithSidebar viewer={viewer} />} />
|
||||
{/* §14.5 / §14.6: cookie-consent companions to /philosophy.
|
||||
Available to anonymous and authenticated viewers alike. */}
|
||||
<Route path="/privacy" element={<PolicyShell><Privacy /></PolicyShell>} />
|
||||
@@ -221,6 +226,14 @@ function PhilosophyWithSidebar({ viewer }) {
|
||||
)
|
||||
}
|
||||
|
||||
function DocsWithSidebar({ viewer }) {
|
||||
return (
|
||||
<main className="chrome-pane">
|
||||
<Docs authenticated={!!viewer} />
|
||||
</main>
|
||||
)
|
||||
}
|
||||
|
||||
function NotificationSettingsWithSidebar({ viewer }) {
|
||||
return (
|
||||
<main className="chrome-pane">
|
||||
|
||||
+57
-2
@@ -31,11 +31,19 @@ export async function getMe() {
|
||||
// migration — the new UI just no longer points at it primarily. These
|
||||
// two helpers drive the Login.jsx surface.
|
||||
|
||||
export async function requestOtc(email) {
|
||||
export async function requestOtc(email, { turnstileToken } = {}) {
|
||||
// v0.12.0 / roadmap item #10: when the Turnstile widget has produced
|
||||
// a token, send it alongside the email so the backend can siteverify
|
||||
// before the OTC dispatch. The backend treats a missing token as
|
||||
// either soft-fail (no secret wired AND TURNSTILE_REQUIRED=false)
|
||||
// or hard-fail (verification required) — the frontend stays
|
||||
// uninvolved in the policy.
|
||||
const body = { email }
|
||||
if (turnstileToken) body.turnstile_token = turnstileToken
|
||||
const res = await fetch('/auth/otc/request', {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify({ email }),
|
||||
body: JSON.stringify(body),
|
||||
})
|
||||
return jsonOrThrow(res)
|
||||
}
|
||||
@@ -65,6 +73,49 @@ export async function submitBetaRequest({ first_name, last_name, beta_request_re
|
||||
return jsonOrThrow(res)
|
||||
}
|
||||
|
||||
// ── v0.10.0: user-set passcodes after OTC (§6.2, roadmap item #8) ─────────
|
||||
//
|
||||
// After a successful OTC sign-in, a contributor may set a passcode and
|
||||
// use email + passcode for subsequent sign-ins. OTC remains the
|
||||
// forgot-passcode fallback — 5 consecutive verify failures locks the
|
||||
// passcode path for 15 minutes (HTTP 423); the OTC path is unaffected.
|
||||
|
||||
export async function checkPasscode(email) {
|
||||
// Anonymous endpoint. Returns `{has_passcode: boolean}` so the
|
||||
// Login.jsx flow can decide whether to render a passcode input or
|
||||
// fall back to OTC. We URL-encode the email so addresses with '+'
|
||||
// round-trip cleanly.
|
||||
const params = new URLSearchParams({ email })
|
||||
const res = await fetch(`/auth/passcode/check?${params}`)
|
||||
return jsonOrThrow(res)
|
||||
}
|
||||
|
||||
export async function verifyPasscode(email, passcode) {
|
||||
const res = await fetch('/auth/passcode/verify', {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify({ email, passcode }),
|
||||
})
|
||||
return jsonOrThrow(res)
|
||||
}
|
||||
|
||||
export async function setPasscode(passcode) {
|
||||
// Requires an active session — the server returns 401 if not signed
|
||||
// in. The signed-in user is the implicit subject; the body carries
|
||||
// only the new passcode.
|
||||
const res = await fetch('/auth/passcode/set', {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify({ passcode }),
|
||||
})
|
||||
return jsonOrThrow(res)
|
||||
}
|
||||
|
||||
export async function clearPasscode() {
|
||||
const res = await fetch('/auth/passcode', { method: 'DELETE' })
|
||||
return jsonOrThrow(res)
|
||||
}
|
||||
|
||||
export async function listRFCs() {
|
||||
return jsonOrThrow(await fetch('/api/rfcs'))
|
||||
}
|
||||
@@ -589,6 +640,10 @@ export async function getPhilosophy() {
|
||||
return jsonOrThrow(await fetch('/api/philosophy'))
|
||||
}
|
||||
|
||||
export async function getDocs() {
|
||||
return jsonOrThrow(await fetch('/api/docs'))
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Slice 7: admin neighborhood (§17 admin/* + user search for the §15.8 mute
|
||||
// typeahead).
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
// `/docs` — the user-facing guide.
|
||||
//
|
||||
// Sibling of Philosophy.jsx: same chrome, same data path, different
|
||||
// source file. Renders DOCS.md verbatim with light chrome around it.
|
||||
// Reachable anonymously, same as `/philosophy`, so a visitor can read
|
||||
// the guide before deciding to sign in.
|
||||
|
||||
import { useEffect, useState } from 'react'
|
||||
import { Link, useNavigate } from 'react-router-dom'
|
||||
import MarkdownPreview from './MarkdownPreview.jsx'
|
||||
import { getDocs } from '../api.js'
|
||||
|
||||
export default function Docs({ authenticated }) {
|
||||
const [body, setBody] = useState('')
|
||||
const [error, setError] = useState(null)
|
||||
const [loading, setLoading] = useState(true)
|
||||
const navigate = useNavigate()
|
||||
|
||||
useEffect(() => {
|
||||
let active = true
|
||||
getDocs()
|
||||
.then(r => { if (active) setBody(r.body || '') })
|
||||
.catch(e => { if (active) setError(e.message || String(e)) })
|
||||
.finally(() => { if (active) setLoading(false) })
|
||||
return () => { active = false }
|
||||
}, [])
|
||||
|
||||
return (
|
||||
<div className="philosophy-page">
|
||||
<header className="philosophy-header">
|
||||
<button
|
||||
className="philosophy-back"
|
||||
onClick={() => (history.length > 1 ? navigate(-1) : navigate('/'))}
|
||||
>
|
||||
← Back
|
||||
</button>
|
||||
<span className="philosophy-title">User guide</span>
|
||||
{!authenticated && (
|
||||
<Link className="philosophy-signin" to="/">Home</Link>
|
||||
)}
|
||||
</header>
|
||||
<article className="philosophy-body">
|
||||
{loading && <p className="muted">Loading…</p>}
|
||||
{error && <p className="error">Could not load the guide: {error}</p>}
|
||||
{!loading && !error && (
|
||||
<MarkdownPreview content={body} />
|
||||
)}
|
||||
</article>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
@@ -1,57 +1,131 @@
|
||||
// Login.jsx — v0.7.0's primary sign-in surface (§6.2), extended by
|
||||
// v0.8.0 (§6.1 / §14.1, roadmap item #6) with the first-OTC profile
|
||||
// capture step.
|
||||
// Login.jsx — the composed sign-in surface (§6.2) after the v0.12.0
|
||||
// (CloudFlare Turnstile gate on OTC dispatch, roadmap item #10) /
|
||||
// v0.10.0 (passcodes, roadmap item #8) rebase onto v0.8.0
|
||||
// (beta-access-request capture, §6.1 / §14.1, roadmap item #6). v0.7.0
|
||||
// (roadmap item #5) established the email + OTC scaffolding the later
|
||||
// releases extended.
|
||||
//
|
||||
// Three-step (the third is conditional):
|
||||
// 1. Enter email → POST /auth/otc/request → on 200, advance.
|
||||
// On 429 (rate-limit), surface a "wait a moment" hint and keep
|
||||
// the user on step 1.
|
||||
// 2. Enter the six-digit code from the email → POST /auth/otc/verify
|
||||
// → on 200, the response body carries `needs_profile`:
|
||||
// * needs_profile=false (returning user, OAuth-era grandfather,
|
||||
// or already-captured pending user): redirect to "/".
|
||||
// * needs_profile=true (fresh OTC sign-in, no profile fields
|
||||
// yet): advance to step 3.
|
||||
// Cmd/Ctrl+Enter on the code field is the keyboard shortcut.
|
||||
// 3. First name, last name, and "why I should be included in the
|
||||
// beta" → POST /api/auth/me/beta-request → redirect to
|
||||
// /beta-pending. The user's row stays `permission_state='pending'`
|
||||
// until an admin grants access.
|
||||
// v0.12.0: the email-entry step renders a Turnstile widget. The token
|
||||
// it produces is sent to `/auth/otc/request` alongside the email. The
|
||||
// passcode step also renders a widget for the "Use a code instead"
|
||||
// fallback dispatch (same backend endpoint, same gate). When the
|
||||
// `VITE_TURNSTILE_SITE_KEY` build var is unset, the widget renders
|
||||
// nothing — the form still submits and the backend's TURNSTILE_REQUIRED
|
||||
// policy decides admission.
|
||||
//
|
||||
// Server-side, /auth/otc/request returns 202 uniformly so abuse paths
|
||||
// (e.g. distributed allowlist-probing) don't leak the recognized-email
|
||||
// set. This surface never distinguishes "we couldn't reach you" from
|
||||
// "we don't know you" — it just advances to step 2. If a request was
|
||||
// rate-limited, the user sees a 429 hint and stays on step 1.
|
||||
// Four-to-six-step flow (most users see three; the longest path is
|
||||
// pending-user with no passcode, who never sees the passcode steps):
|
||||
//
|
||||
// The legacy Gitea OAuth callback remains at /auth/login → /auth/callback
|
||||
// during the migration; we surface a "Sign in with Gitea" link as a
|
||||
// fallback in the footer so users with active OAuth sessions or older
|
||||
// invite emails still have a path.
|
||||
// 1. 'email' Enter email → GET /auth/passcode/check.
|
||||
// * has_passcode=true → step 'passcode'.
|
||||
// * has_passcode=false → POST /auth/otc/request,
|
||||
// step 'code'.
|
||||
// 429 on either dispatch surfaces a "wait a
|
||||
// moment" hint and keeps the user on step 1.
|
||||
//
|
||||
// 2a. 'passcode' Enter passcode → POST /auth/passcode/verify.
|
||||
// * 200 → redirect to "/".
|
||||
// * 423 (lockout, 5 consecutive failures) →
|
||||
// auto-fall back to OTC by requesting a fresh
|
||||
// code and advancing to step 'code'.
|
||||
// * 400 → wrong passcode; user can retry or
|
||||
// click "Use a code instead" to fall back
|
||||
// manually.
|
||||
//
|
||||
// 2b. 'code' Enter the six-digit code → POST /auth/otc/verify.
|
||||
// On 200, fetch /api/auth/me and branch:
|
||||
// * needs_profile === true → 'capture-profile'
|
||||
// * has_passcode === false → 'offer-passcode'
|
||||
// * otherwise → redirect to "/".
|
||||
// needs_profile WINS over has_passcode — a
|
||||
// pending user goes through the §6.1 capture
|
||||
// flow first; setting a passcode while waiting
|
||||
// for admin grant gains them nothing.
|
||||
// Cmd/Ctrl+Enter on the code field is the
|
||||
// keyboard shortcut.
|
||||
//
|
||||
// 3. 'capture-profile' (v0.8.0, §6.1) First name, last name, and "why
|
||||
// I should be included in the beta" → POST
|
||||
// /api/auth/me/beta-request → redirect to
|
||||
// /beta-pending. The user's row stays
|
||||
// permission_state='pending' until an admin
|
||||
// grants access; they can set a passcode later
|
||||
// from settings, or on a future sign-in once
|
||||
// granted.
|
||||
//
|
||||
// 4a. 'offer-passcode' (v0.10.0) "Set a passcode for faster sign-in
|
||||
// next time?" Yes → 'set-passcode'. Skip → "/".
|
||||
//
|
||||
// 4b. 'set-passcode' Pick a passcode (4–20 chars) → POST
|
||||
// /auth/passcode/set → redirect to "/". A
|
||||
// "Skip for now" link also redirects to "/".
|
||||
//
|
||||
// Server-side, /auth/otc/request returns 202 uniformly and
|
||||
// /auth/passcode/check returns has_passcode=false for an unknown
|
||||
// email, so this surface never distinguishes "we couldn't reach you"
|
||||
// from "we don't know you" — an unknown email always lands in the
|
||||
// OTC path with no account-enumeration signal.
|
||||
//
|
||||
// The legacy Gitea OAuth callback remains at /auth/login →
|
||||
// /auth/callback during the v0.7.0 migration; we surface a "Sign in
|
||||
// with Gitea" link as a fallback in the footer so users with active
|
||||
// OAuth sessions or older invite emails still have a path. We hide
|
||||
// the fallback on 'capture-profile' so a half-captured pending user
|
||||
// doesn't bail out into the OAuth path mid-form.
|
||||
|
||||
import { useEffect, useRef, useState } from 'react'
|
||||
import { useNavigate, Link } from 'react-router-dom'
|
||||
import { requestOtc, verifyOtc, submitBetaRequest } from '../api'
|
||||
import {
|
||||
requestOtc,
|
||||
verifyOtc,
|
||||
submitBetaRequest,
|
||||
checkPasscode,
|
||||
verifyPasscode,
|
||||
setPasscode as apiSetPasscode,
|
||||
} from '../api'
|
||||
import TurnstileWidget, { turnstileEnabled } from './TurnstileWidget'
|
||||
|
||||
export default function Login() {
|
||||
// Steps: 'email' → 'passcode' or 'code' → (on the OTC path, after
|
||||
// verify) one of: 'capture-profile' (pending user), 'offer-passcode'
|
||||
// (no passcode yet), or straight to "/". 'set-passcode' is reached
|
||||
// from 'offer-passcode'.
|
||||
const [step, setStep] = useState('email')
|
||||
const [email, setEmail] = useState('')
|
||||
const [code, setCode] = useState('')
|
||||
// v0.8.0 — step 3 capture fields.
|
||||
const [passcode, setPasscode] = useState('')
|
||||
const [newPasscode, setNewPasscode] = useState('')
|
||||
// v0.8.0 — capture-profile fields.
|
||||
const [firstName, setFirstName] = useState('')
|
||||
const [lastName, setLastName] = useState('')
|
||||
const [reason, setReason] = useState('')
|
||||
const [status, setStatus] = useState('')
|
||||
const [busy, setBusy] = useState(false)
|
||||
// v0.12.0: Turnstile token captured by the widget. `null` means no
|
||||
// challenge solved yet (or the site key is unset, in which case the
|
||||
// widget surfaces null on mount). The token is single-use; we clear
|
||||
// it back to null right after we send it so a second request on the
|
||||
// same form remount re-challenges. `turnstileReady` is true once the
|
||||
// widget has produced a token OR the widget is not configured at
|
||||
// build time (no site key) — the submit button reads from it so the
|
||||
// form locks up when the operator has wired Turnstile but the user
|
||||
// hasn't solved the challenge yet.
|
||||
const [turnstileToken, setTurnstileToken] = useState(null)
|
||||
const turnstileOn = turnstileEnabled()
|
||||
const turnstileReady = !turnstileOn || !!turnstileToken
|
||||
const emailRef = useRef(null)
|
||||
const codeRef = useRef(null)
|
||||
const passcodeRef = useRef(null)
|
||||
const newPasscodeRef = useRef(null)
|
||||
const firstNameRef = useRef(null)
|
||||
const navigate = useNavigate()
|
||||
|
||||
useEffect(() => {
|
||||
if (step === 'email') emailRef.current?.focus()
|
||||
else if (step === 'code') codeRef.current?.focus()
|
||||
else if (step === 'profile') firstNameRef.current?.focus()
|
||||
else if (step === 'passcode') passcodeRef.current?.focus()
|
||||
else if (step === 'capture-profile') firstNameRef.current?.focus()
|
||||
else if (step === 'set-passcode') newPasscodeRef.current?.focus()
|
||||
}, [step])
|
||||
|
||||
async function submitEmail(e) {
|
||||
@@ -63,20 +137,93 @@ export default function Login() {
|
||||
setBusy(true)
|
||||
setStatus('')
|
||||
try {
|
||||
await requestOtc(email.trim())
|
||||
setStep('code')
|
||||
setStatus('Check your inbox — a six-digit code is on the way.')
|
||||
const { has_passcode } = await checkPasscode(email.trim())
|
||||
if (has_passcode) {
|
||||
setStep('passcode')
|
||||
setStatus('')
|
||||
} else {
|
||||
await requestOtc(email.trim(), { turnstileToken })
|
||||
// v0.12.0: the token is single-use; drop it so a re-request
|
||||
// from the code step (via "Use a different email" → back to
|
||||
// email) starts with a fresh challenge.
|
||||
setTurnstileToken(null)
|
||||
setStep('code')
|
||||
setStatus('Check your inbox — a six-digit code is on the way.')
|
||||
}
|
||||
} catch (err) {
|
||||
// Any failure consumes the token from CloudFlare's side; clear
|
||||
// so the widget re-renders a fresh challenge on retry.
|
||||
setTurnstileToken(null)
|
||||
if (err.status === 429) {
|
||||
setStatus('Slow down — wait a minute before requesting another code.')
|
||||
} else if (err.status === 400) {
|
||||
setStatus("Couldn't verify you're human. Please retry the challenge.")
|
||||
} else {
|
||||
setStatus(err.message || 'Could not request a code. Try again.')
|
||||
setStatus(err.message || 'Could not start sign-in. Try again.')
|
||||
}
|
||||
} finally {
|
||||
setBusy(false)
|
||||
}
|
||||
}
|
||||
|
||||
async function submitPasscode(e) {
|
||||
if (e) e.preventDefault()
|
||||
if (!passcode.trim()) {
|
||||
setStatus('Enter your passcode.')
|
||||
return
|
||||
}
|
||||
setBusy(true)
|
||||
setStatus('')
|
||||
try {
|
||||
await verifyPasscode(email.trim(), passcode.trim())
|
||||
// Reload so App.jsx's getMe() picks up the fresh session. A
|
||||
// returning passcode user is by definition already past the
|
||||
// §6.1 capture step (they couldn't have set a passcode while
|
||||
// pending), so we go straight to "/".
|
||||
window.location.assign('/')
|
||||
} catch (err) {
|
||||
if (err.status === 423) {
|
||||
// Lockout — auto-fall back to OTC. The OTC request endpoint
|
||||
// is independent of the passcode lockout, so this lands a
|
||||
// fresh code in the user's inbox immediately.
|
||||
setPasscode('')
|
||||
try {
|
||||
// v0.12.0: pass whatever token the widget on the passcode
|
||||
// step has produced. If the operator has Turnstile required
|
||||
// and the user hasn't solved the passcode-step widget, the
|
||||
// backend refuses and we bounce them back to email-entry
|
||||
// with a clear status (see catch below).
|
||||
await requestOtc(email.trim(), { turnstileToken })
|
||||
setTurnstileToken(null)
|
||||
setStep('code')
|
||||
setStatus(
|
||||
'Too many failed attempts. We sent a one-time code to your email — use it to sign in.',
|
||||
)
|
||||
} catch (e2) {
|
||||
setTurnstileToken(null)
|
||||
if (e2.status === 429) {
|
||||
setStep('code')
|
||||
setStatus(
|
||||
'Too many failed attempts. Wait a minute, then request a one-time code to sign in.',
|
||||
)
|
||||
} else if (e2.status === 400) {
|
||||
setStep('email')
|
||||
setStatus(
|
||||
'Too many failed attempts. Solve the challenge below to receive a one-time code.',
|
||||
)
|
||||
} else {
|
||||
setStatus(
|
||||
'Too many failed attempts. Use the "Use a code instead" link to sign in via email.',
|
||||
)
|
||||
}
|
||||
}
|
||||
} else {
|
||||
setStatus('Wrong passcode. Try again, or use a one-time code instead.')
|
||||
}
|
||||
setBusy(false)
|
||||
}
|
||||
}
|
||||
|
||||
async function submitCode(e) {
|
||||
if (e) e.preventDefault()
|
||||
if (!code.trim() || code.trim().length !== 6) {
|
||||
@@ -86,22 +233,39 @@ export default function Login() {
|
||||
setBusy(true)
|
||||
setStatus('')
|
||||
try {
|
||||
const result = await verifyOtc(email.trim(), code.trim())
|
||||
// v0.8.0 — a fresh OTC user lands in `permission_state='pending'`
|
||||
// with no profile fields. The verify response now carries a
|
||||
// `needs_profile` flag the server stamped from the row state;
|
||||
// surface the capture form here instead of jumping straight to
|
||||
// "/". The fallback path (no flag, e.g. an older backend
|
||||
// before the migration ran) jumps to "/" as before.
|
||||
if (result?.needs_profile) {
|
||||
setStep('profile')
|
||||
await verifyOtc(email.trim(), code.trim())
|
||||
// OTC verified — the server has signed in the user. Fetch the
|
||||
// canonical /api/auth/me to decide where to land:
|
||||
// * needs_profile → §6.1 capture (then /beta-pending).
|
||||
// * no passcode → §6.2 offer-passcode (then /).
|
||||
// * otherwise → /.
|
||||
// needs_profile wins over has_passcode: a pending user can't yet
|
||||
// do anything that benefits from faster sign-in, so we don't
|
||||
// distract them with the passcode offer mid-admission.
|
||||
const meResp = await fetch('/api/auth/me', { credentials: 'include' })
|
||||
let me = null
|
||||
if (meResp.ok) {
|
||||
try {
|
||||
me = await meResp.json()
|
||||
} catch (_) {
|
||||
me = null
|
||||
}
|
||||
}
|
||||
if (me?.needs_profile === true) {
|
||||
setStep('capture-profile')
|
||||
setStatus('')
|
||||
setBusy(false)
|
||||
return
|
||||
}
|
||||
// Reload so App.jsx's getMe() picks up the fresh session. We
|
||||
// navigate to "/" via a hard load so any cached "anonymous"
|
||||
// view state in memory is dropped cleanly.
|
||||
if (me?.has_passcode === false) {
|
||||
setStep('offer-passcode')
|
||||
setStatus('')
|
||||
setBusy(false)
|
||||
return
|
||||
}
|
||||
// Either /me returned the granted-with-passcode shape, or the
|
||||
// call failed but the session cookie is set — fall through to
|
||||
// a hard reload so App.jsx re-fetches and renders accordingly.
|
||||
window.location.assign('/')
|
||||
} catch (err) {
|
||||
setStatus('That code is invalid or expired. Try again, or request a new code.')
|
||||
@@ -126,10 +290,10 @@ export default function Login() {
|
||||
last_name: ln,
|
||||
beta_request_reason: why,
|
||||
})
|
||||
// The user is still `permission_state='pending'`; bounce them
|
||||
// to /beta-pending so the next thing they see is the
|
||||
// "your request is in review" page. Hard-load so App.jsx
|
||||
// re-fetches /api/auth/me and picks up the captured fields.
|
||||
// Hard-load so App.jsx re-fetches /api/auth/me and picks up
|
||||
// the captured fields. The user stays permission_state='pending'
|
||||
// until an admin grants access — the next thing they should
|
||||
// see is the "your request is in review" page.
|
||||
window.location.assign('/beta-pending')
|
||||
} catch (err) {
|
||||
setStatus(err.message || 'Could not submit your request. Try again.')
|
||||
@@ -137,6 +301,26 @@ export default function Login() {
|
||||
}
|
||||
}
|
||||
|
||||
async function submitNewPasscode(e) {
|
||||
if (e) e.preventDefault()
|
||||
const pc = newPasscode.trim()
|
||||
if (pc.length < 4) {
|
||||
setStatus('Passcode must be at least 4 characters.')
|
||||
return
|
||||
}
|
||||
setBusy(true)
|
||||
setStatus('')
|
||||
try {
|
||||
await apiSetPasscode(pc)
|
||||
window.location.assign('/')
|
||||
} catch (err) {
|
||||
// 422 carries the validation message verbatim (denylist /
|
||||
// length); surface it as-is so the user knows what to change.
|
||||
setStatus(err.message || 'Could not set passcode. Try a different one.')
|
||||
setBusy(false)
|
||||
}
|
||||
}
|
||||
|
||||
function onCodeKey(e) {
|
||||
// §6.2 ergonomic: Cmd/Ctrl+Enter submits from the code field.
|
||||
if ((e.metaKey || e.ctrlKey) && e.key === 'Enter') {
|
||||
@@ -144,12 +328,69 @@ export default function Login() {
|
||||
}
|
||||
}
|
||||
|
||||
function onPasscodeKey(e) {
|
||||
if ((e.metaKey || e.ctrlKey) && e.key === 'Enter') {
|
||||
submitPasscode(e)
|
||||
}
|
||||
}
|
||||
|
||||
function onReasonKey(e) {
|
||||
// §6.1 ergonomic: Cmd/Ctrl+Enter submits the capture form from
|
||||
// the reason textarea (the multi-line input that would otherwise
|
||||
// swallow Enter as a newline).
|
||||
if ((e.metaKey || e.ctrlKey) && e.key === 'Enter') {
|
||||
submitProfile(e)
|
||||
}
|
||||
}
|
||||
|
||||
function onNewPasscodeKey(e) {
|
||||
if ((e.metaKey || e.ctrlKey) && e.key === 'Enter') {
|
||||
submitNewPasscode(e)
|
||||
}
|
||||
}
|
||||
|
||||
function backToEmail() {
|
||||
setStep('email')
|
||||
setCode('')
|
||||
setPasscode('')
|
||||
setStatus('')
|
||||
}
|
||||
|
||||
async function fallbackToOtc() {
|
||||
// Manual "Use a code instead" from the passcode step. Same shape
|
||||
// as the email-step OTC dispatch. v0.12.0: pass through whatever
|
||||
// Turnstile token the passcode-step widget has produced (or null
|
||||
// when the widget is disabled at build time).
|
||||
setBusy(true)
|
||||
setStatus('')
|
||||
try {
|
||||
await requestOtc(email.trim(), { turnstileToken })
|
||||
setTurnstileToken(null)
|
||||
setPasscode('')
|
||||
setStep('code')
|
||||
setStatus('Check your inbox — a six-digit code is on the way.')
|
||||
} catch (err) {
|
||||
setTurnstileToken(null)
|
||||
if (err.status === 429) {
|
||||
setStatus('Slow down — wait a minute before requesting another code.')
|
||||
} else if (err.status === 400) {
|
||||
// v0.12.0: the widget rejected or no token was sent. Bounce
|
||||
// the user back to the email step so they get a fresh
|
||||
// challenge alongside the email input.
|
||||
setStep('email')
|
||||
setStatus("Couldn't verify you're human. Please retry the challenge.")
|
||||
} else {
|
||||
setStatus(err.message || 'Could not request a code. Try again.')
|
||||
}
|
||||
} finally {
|
||||
setBusy(false)
|
||||
}
|
||||
}
|
||||
|
||||
function skipPasscodeOffer() {
|
||||
window.location.assign('/')
|
||||
}
|
||||
|
||||
return (
|
||||
<div className="otc-login">
|
||||
<div className="otc-login-inner">
|
||||
@@ -157,7 +398,8 @@ export default function Login() {
|
||||
{step === 'email' && (
|
||||
<form onSubmit={submitEmail}>
|
||||
<p className="otc-hint">
|
||||
Enter your email. We'll send you a one-time code.
|
||||
Enter your email. If you've set a passcode, you'll enter that
|
||||
next; otherwise we'll send a one-time code.
|
||||
</p>
|
||||
<input
|
||||
ref={emailRef}
|
||||
@@ -169,11 +411,72 @@ export default function Login() {
|
||||
required
|
||||
disabled={busy}
|
||||
/>
|
||||
<button type="submit" disabled={busy || !email.trim()}>
|
||||
{busy ? 'Sending…' : 'Send code'}
|
||||
{/*
|
||||
v0.12.0: CloudFlare Turnstile widget. Renders nothing
|
||||
when VITE_TURNSTILE_SITE_KEY is unset (and turnstileReady
|
||||
defaults to true in that case so the submit gate doesn't
|
||||
lock up). On every challenge the widget calls onToken
|
||||
with the fresh token; we feed it to /auth/otc/request.
|
||||
*/}
|
||||
<TurnstileWidget onToken={setTurnstileToken} />
|
||||
<button
|
||||
type="submit"
|
||||
disabled={busy || !email.trim() || !turnstileReady}
|
||||
>
|
||||
{busy ? 'Checking…' : 'Continue'}
|
||||
</button>
|
||||
</form>
|
||||
)}
|
||||
{step === 'passcode' && (
|
||||
<form onSubmit={submitPasscode}>
|
||||
<p className="otc-hint">
|
||||
Enter the passcode for <strong>{email}</strong>.
|
||||
</p>
|
||||
<input
|
||||
ref={passcodeRef}
|
||||
type="password"
|
||||
autoComplete="current-password"
|
||||
value={passcode}
|
||||
onChange={e => setPasscode(e.target.value)}
|
||||
onKeyDown={onPasscodeKey}
|
||||
placeholder="Your passcode"
|
||||
required
|
||||
disabled={busy}
|
||||
/>
|
||||
{/*
|
||||
v0.12.0: a second Turnstile widget for the
|
||||
"Use a code instead" fallback dispatch. The passcode
|
||||
verify path does not consume a Turnstile token (it has
|
||||
its own 5-attempt lockout shape from v0.10.0), but if
|
||||
the user falls back to OTC the same /auth/otc/request
|
||||
endpoint runs and needs a token. We render the widget
|
||||
on this step too so the fallback works without bouncing
|
||||
back to email-entry first.
|
||||
*/}
|
||||
<TurnstileWidget onToken={setTurnstileToken} />
|
||||
<div className="otc-actions">
|
||||
<button type="submit" disabled={busy || !passcode.trim()}>
|
||||
{busy ? 'Signing in…' : 'Sign in'}
|
||||
</button>
|
||||
<button
|
||||
type="button"
|
||||
className="btn-link-quiet"
|
||||
onClick={fallbackToOtc}
|
||||
disabled={busy || !turnstileReady}
|
||||
>
|
||||
Use a code instead
|
||||
</button>
|
||||
<button
|
||||
type="button"
|
||||
className="btn-link-quiet"
|
||||
onClick={backToEmail}
|
||||
disabled={busy}
|
||||
>
|
||||
Use a different email
|
||||
</button>
|
||||
</div>
|
||||
</form>
|
||||
)}
|
||||
{step === 'code' && (
|
||||
<form onSubmit={submitCode}>
|
||||
<p className="otc-hint">
|
||||
@@ -211,7 +514,7 @@ export default function Login() {
|
||||
</p>
|
||||
</form>
|
||||
)}
|
||||
{step === 'profile' && (
|
||||
{step === 'capture-profile' && (
|
||||
<form onSubmit={submitProfile}>
|
||||
<p className="otc-hint">
|
||||
You're signed in. {import.meta.env.VITE_APP_NAME} is in private
|
||||
@@ -245,6 +548,7 @@ export default function Login() {
|
||||
<textarea
|
||||
value={reason}
|
||||
onChange={e => setReason(e.target.value)}
|
||||
onKeyDown={onReasonKey}
|
||||
required
|
||||
disabled={busy}
|
||||
rows={5}
|
||||
@@ -259,10 +563,71 @@ export default function Login() {
|
||||
{busy ? 'Submitting…' : 'Submit request'}
|
||||
</button>
|
||||
</div>
|
||||
<p className="otc-shortcut-hint">
|
||||
Tip: <kbd>⌘</kbd>+<kbd>Enter</kbd> (or <kbd>Ctrl</kbd>+<kbd>Enter</kbd>) to submit.
|
||||
</p>
|
||||
</form>
|
||||
)}
|
||||
{step === 'offer-passcode' && (
|
||||
<div className="otc-offer-passcode">
|
||||
<p className="otc-hint">
|
||||
You're signed in. Want to set a passcode for faster sign-in
|
||||
next time? You can always use a one-time code instead — and
|
||||
you can change or remove the passcode from your settings.
|
||||
</p>
|
||||
<div className="otc-actions">
|
||||
<button
|
||||
type="button"
|
||||
onClick={() => { setStep('set-passcode'); setStatus('') }}
|
||||
>
|
||||
Set a passcode
|
||||
</button>
|
||||
<button
|
||||
type="button"
|
||||
className="btn-link-quiet"
|
||||
onClick={skipPasscodeOffer}
|
||||
>
|
||||
Skip for now
|
||||
</button>
|
||||
</div>
|
||||
</div>
|
||||
)}
|
||||
{step === 'set-passcode' && (
|
||||
<form onSubmit={submitNewPasscode}>
|
||||
<p className="otc-hint">
|
||||
Pick a passcode (4–20 characters). You'll use it with your
|
||||
email to sign in next time.
|
||||
</p>
|
||||
<input
|
||||
ref={newPasscodeRef}
|
||||
type="password"
|
||||
autoComplete="new-password"
|
||||
value={newPasscode}
|
||||
onChange={e => setNewPasscode(e.target.value)}
|
||||
onKeyDown={onNewPasscodeKey}
|
||||
placeholder="New passcode"
|
||||
required
|
||||
disabled={busy}
|
||||
minLength={4}
|
||||
maxLength={20}
|
||||
/>
|
||||
<div className="otc-actions">
|
||||
<button type="submit" disabled={busy || newPasscode.trim().length < 4}>
|
||||
{busy ? 'Saving…' : 'Save passcode'}
|
||||
</button>
|
||||
<button
|
||||
type="button"
|
||||
className="btn-link-quiet"
|
||||
onClick={skipPasscodeOffer}
|
||||
disabled={busy}
|
||||
>
|
||||
Skip for now
|
||||
</button>
|
||||
</div>
|
||||
</form>
|
||||
)}
|
||||
{status && <p className="otc-status">{status}</p>}
|
||||
{step !== 'profile' && (
|
||||
{step !== 'capture-profile' && (
|
||||
<p className="otc-fallback">
|
||||
<Link to="/philosophy">Read the philosophy →</Link>
|
||||
<span className="otc-fallback-sep">·</span>
|
||||
|
||||
@@ -29,6 +29,9 @@ import {
|
||||
muteUser,
|
||||
searchUsers,
|
||||
getCookieConsent,
|
||||
getMe,
|
||||
setPasscode,
|
||||
clearPasscode,
|
||||
} from '../api.js'
|
||||
import { getConsent, onConsentChange, hydrateFromServer } from '../lib/consent.js'
|
||||
|
||||
@@ -50,11 +53,167 @@ export default function NotificationSettings({ viewer }) {
|
||||
<QuietHoursSection />
|
||||
<WatchesSection />
|
||||
<MutesSection viewer={viewer} />
|
||||
<SignInSection />
|
||||
<PrivacyCookiesSection />
|
||||
</div>
|
||||
)
|
||||
}
|
||||
|
||||
// ── §6.2 sign-in (v0.10.0 / roadmap item #8): passcode management ──────────
|
||||
|
||||
function SignInSection() {
|
||||
// Source of truth for `has_passcode` and `passcode_set_at` is the
|
||||
// /api/auth/me payload (v0.10.0 added both fields). We re-read after
|
||||
// every mutation so the surface reflects what just landed.
|
||||
const [me, setMe] = useState(null)
|
||||
const [error, setError] = useState(null)
|
||||
const [mode, setMode] = useState('idle') // 'idle' | 'set' | 'change'
|
||||
const [draft, setDraft] = useState('')
|
||||
const [busy, setBusy] = useState(false)
|
||||
const [savedNote, setSavedNote] = useState('')
|
||||
|
||||
useEffect(() => {
|
||||
getMe()
|
||||
.then(payload => setMe(payload.user || null))
|
||||
.catch(e => setError(e.message))
|
||||
}, [])
|
||||
|
||||
async function refresh() {
|
||||
const payload = await getMe()
|
||||
setMe(payload.user || null)
|
||||
}
|
||||
|
||||
async function save(e) {
|
||||
if (e) e.preventDefault()
|
||||
const pc = draft.trim()
|
||||
if (pc.length < 4) {
|
||||
setError('Passcode must be at least 4 characters.')
|
||||
return
|
||||
}
|
||||
setBusy(true)
|
||||
setError(null)
|
||||
setSavedNote('')
|
||||
try {
|
||||
await setPasscode(pc)
|
||||
setDraft('')
|
||||
setMode('idle')
|
||||
setSavedNote('Passcode saved.')
|
||||
await refresh()
|
||||
} catch (err) {
|
||||
// 422 carries the validation message verbatim (denylist /
|
||||
// length); surface it as-is so the user knows what to change.
|
||||
setError(err.message || 'Could not save passcode. Try a different one.')
|
||||
} finally {
|
||||
setBusy(false)
|
||||
setTimeout(() => setSavedNote(''), 2000)
|
||||
}
|
||||
}
|
||||
|
||||
async function remove() {
|
||||
if (!confirm('Remove your passcode? You will sign in with a one-time code next time.')) {
|
||||
return
|
||||
}
|
||||
setBusy(true)
|
||||
setError(null)
|
||||
setSavedNote('')
|
||||
try {
|
||||
await clearPasscode()
|
||||
setSavedNote('Passcode removed.')
|
||||
await refresh()
|
||||
} catch (err) {
|
||||
setError(err.message || 'Could not remove passcode.')
|
||||
} finally {
|
||||
setBusy(false)
|
||||
setTimeout(() => setSavedNote(''), 2000)
|
||||
}
|
||||
}
|
||||
|
||||
if (!me) return <SectionShell title="Sign-in" subtitle={error || 'Loading…'} />
|
||||
|
||||
const hasPasscode = !!me.has_passcode
|
||||
|
||||
return (
|
||||
<SectionShell
|
||||
title="Sign-in"
|
||||
subtitle="How you sign in. A passcode lets you skip the one-time-code email; the one-time-code path is always available as a fallback (and as the recovery path if you forget your passcode)."
|
||||
>
|
||||
<div className="settings-row">
|
||||
<span className="settings-note">
|
||||
<strong>Passcode:</strong>{' '}
|
||||
{hasPasscode ? 'Set.' : 'Not set — you sign in with a one-time code each time.'}
|
||||
</span>
|
||||
</div>
|
||||
{hasPasscode && me.passcode_set_at && (
|
||||
<p className="settings-note muted">Set on {me.passcode_set_at}.</p>
|
||||
)}
|
||||
|
||||
{mode === 'idle' && (
|
||||
<div className="settings-row">
|
||||
{hasPasscode ? (
|
||||
<>
|
||||
<button
|
||||
className="btn-primary"
|
||||
onClick={() => { setMode('change'); setDraft(''); setError(null) }}
|
||||
disabled={busy}
|
||||
>
|
||||
Change passcode
|
||||
</button>
|
||||
<button
|
||||
className="btn-link-muted"
|
||||
onClick={remove}
|
||||
disabled={busy}
|
||||
>
|
||||
Remove passcode
|
||||
</button>
|
||||
</>
|
||||
) : (
|
||||
<button
|
||||
className="btn-primary"
|
||||
onClick={() => { setMode('set'); setDraft(''); setError(null) }}
|
||||
disabled={busy}
|
||||
>
|
||||
Set passcode
|
||||
</button>
|
||||
)}
|
||||
</div>
|
||||
)}
|
||||
|
||||
{(mode === 'set' || mode === 'change') && (
|
||||
<form className="settings-row" onSubmit={save}>
|
||||
<label>
|
||||
{mode === 'change' ? 'New passcode' : 'Passcode'}
|
||||
<input
|
||||
type="password"
|
||||
autoComplete="new-password"
|
||||
value={draft}
|
||||
onChange={e => setDraft(e.target.value)}
|
||||
placeholder="4–20 characters"
|
||||
minLength={4}
|
||||
maxLength={20}
|
||||
required
|
||||
disabled={busy}
|
||||
/>
|
||||
</label>
|
||||
<button className="btn-primary" type="submit" disabled={busy || draft.trim().length < 4}>
|
||||
{busy ? 'Saving…' : 'Save'}
|
||||
</button>
|
||||
<button
|
||||
type="button"
|
||||
className="btn-link-muted"
|
||||
onClick={() => { setMode('idle'); setDraft(''); setError(null) }}
|
||||
disabled={busy}
|
||||
>
|
||||
Cancel
|
||||
</button>
|
||||
</form>
|
||||
)}
|
||||
|
||||
{savedNote && <p className="settings-note">{savedNote}</p>}
|
||||
{error && <p className="settings-note warning">{error}</p>}
|
||||
</SectionShell>
|
||||
)
|
||||
}
|
||||
|
||||
// ── §14.5 cookie / privacy consent (v0.13.0 / roadmap item #11) ────────────
|
||||
|
||||
function PrivacyCookiesSection() {
|
||||
|
||||
@@ -0,0 +1,120 @@
|
||||
// TurnstileWidget.jsx — v0.12.0 / roadmap item #10.
|
||||
//
|
||||
// Renders the CloudFlare Turnstile JS widget on the email-entry step of
|
||||
// `/login`. Reads the site key from `import.meta.env.VITE_TURNSTILE_SITE_KEY`
|
||||
// (Vite convention — VITE_* prefix is build-time embedded). When the
|
||||
// site key is unset/empty, this component renders nothing and reports
|
||||
// a `null` token through `onToken` so the parent form can still submit.
|
||||
// The backend's `TURNSTILE_REQUIRED` policy decides what happens to a
|
||||
// request that arrives without a token; the frontend is intentionally
|
||||
// not in that loop. See `backend/app/turnstile.py` for the matrix.
|
||||
//
|
||||
// The CloudFlare script is loaded once per page on first widget mount.
|
||||
// Subsequent mounts (e.g. user goes back to email-entry after a failed
|
||||
// OTC request) reuse the script tag and re-render the widget on the
|
||||
// fresh container `div`. Unmounting removes the widget instance via
|
||||
// `turnstile.remove(widgetId)` so a remount produces a new challenge
|
||||
// rather than reusing a stale, already-consumed token.
|
||||
//
|
||||
// Turnstile contract:
|
||||
// * `data-callback` fires with the token string on a successful
|
||||
// challenge; the token is single-use and expires after ~5 minutes.
|
||||
// * `data-error-callback` fires on a failed challenge (network,
|
||||
// blocked, etc.); we surface a `null` token so the parent shows
|
||||
// a retry hint.
|
||||
// * `data-expired-callback` fires when the token times out before
|
||||
// submission; we also drop to `null` and re-render so the user
|
||||
// gets a fresh challenge on retry.
|
||||
//
|
||||
// We do **not** import the CloudFlare script at build time; loading it
|
||||
// dynamically here keeps the bundle clean of an external request the
|
||||
// page may not need (anonymous viewers reading RFCs never see Login).
|
||||
|
||||
import { useEffect, useRef } from 'react'
|
||||
|
||||
const TURNSTILE_SCRIPT_URL = 'https://challenges.cloudflare.com/turnstile/v0/api.js'
|
||||
const SITE_KEY = import.meta.env.VITE_TURNSTILE_SITE_KEY || ''
|
||||
|
||||
// Promise-keyed: only one script tag, only one resolution chain.
|
||||
let scriptLoadPromise = null
|
||||
|
||||
function loadTurnstileScript() {
|
||||
if (typeof window === 'undefined') return Promise.resolve(null)
|
||||
if (window.turnstile) return Promise.resolve(window.turnstile)
|
||||
if (scriptLoadPromise) return scriptLoadPromise
|
||||
|
||||
scriptLoadPromise = new Promise((resolve, reject) => {
|
||||
const existing = document.querySelector(`script[src="${TURNSTILE_SCRIPT_URL}"]`)
|
||||
if (existing) {
|
||||
existing.addEventListener('load', () => resolve(window.turnstile))
|
||||
existing.addEventListener('error', reject)
|
||||
return
|
||||
}
|
||||
const script = document.createElement('script')
|
||||
script.src = TURNSTILE_SCRIPT_URL
|
||||
script.async = true
|
||||
script.defer = true
|
||||
script.addEventListener('load', () => resolve(window.turnstile))
|
||||
script.addEventListener('error', reject)
|
||||
document.head.appendChild(script)
|
||||
})
|
||||
return scriptLoadPromise
|
||||
}
|
||||
|
||||
export function turnstileEnabled() {
|
||||
return !!SITE_KEY
|
||||
}
|
||||
|
||||
export default function TurnstileWidget({ onToken, theme = 'auto' }) {
|
||||
const containerRef = useRef(null)
|
||||
const widgetIdRef = useRef(null)
|
||||
|
||||
useEffect(() => {
|
||||
if (!SITE_KEY) {
|
||||
// No site key configured → surface a null token immediately so
|
||||
// the parent form's submit-disabled gate doesn't lock up
|
||||
// waiting on a challenge that will never arrive. The backend
|
||||
// decides whether a tokenless request is admitted.
|
||||
onToken?.(null)
|
||||
return undefined
|
||||
}
|
||||
|
||||
let cancelled = false
|
||||
loadTurnstileScript()
|
||||
.then(turnstile => {
|
||||
if (cancelled || !turnstile || !containerRef.current) return
|
||||
widgetIdRef.current = turnstile.render(containerRef.current, {
|
||||
sitekey: SITE_KEY,
|
||||
theme,
|
||||
callback: token => onToken?.(token),
|
||||
'error-callback': () => onToken?.(null),
|
||||
'expired-callback': () => onToken?.(null),
|
||||
})
|
||||
})
|
||||
.catch(() => {
|
||||
// Script load failure — surface null so the parent can decide
|
||||
// what to do (today: still let submit through; the backend
|
||||
// policy decides admission).
|
||||
if (!cancelled) onToken?.(null)
|
||||
})
|
||||
|
||||
return () => {
|
||||
cancelled = true
|
||||
if (widgetIdRef.current && window.turnstile) {
|
||||
try {
|
||||
window.turnstile.remove(widgetIdRef.current)
|
||||
} catch (_) {
|
||||
// Already gone or never registered — nothing to clean up.
|
||||
}
|
||||
widgetIdRef.current = null
|
||||
}
|
||||
}
|
||||
// We intentionally do not list `onToken` in the dependency array;
|
||||
// a parent re-rendering with a fresh closure should not tear down
|
||||
// and rebuild the widget (which would consume a fresh challenge).
|
||||
// eslint-disable-next-line react-hooks/exhaustive-deps
|
||||
}, [])
|
||||
|
||||
if (!SITE_KEY) return null
|
||||
return <div ref={containerRef} className="turnstile-widget" />
|
||||
}
|
||||
Reference in New Issue
Block a user