7e45bbdbc0
* docs(dialog-pattern): add generic entity-dialog spec Introduceert docs/patterns/dialog.md als bron-of-truth voor elke create/edit/detail-dialog in Scrum4Me, ongeacht het achterliggende dataobject. Bevat 14 secties: uitgangspunten, stack, component- architectuur, layout, validatie, drielaagse demo-policy, submission, dialog-gedrag, theming, footer, triggers/URL-state, per-entiteit profile-template, out-of-scope, en een verificatie-checklist. Registreert het patroon in CLAUDE.md "Implementatiepatronen"-tabel zodat Claude (en mensen) de spec verplicht raadplegen voor elke nieuwe dialog. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(dialog-pattern): convert task spec + add pbi/story entity-profiles Reduceert docs/scrum4me-task-dialog.md van 507 naar ~140 regels: alle gedeelde regels verhuisd naar docs/patterns/dialog.md, dit document bevat nu alleen Task-specifieke velden, URL-pattern, status-veld, server actions, triggers en bewuste out-of-scope-keuzes. Voegt twee nieuwe entity-profielen toe voor bestaande dialogen: - docs/scrum4me-pbi-dialog.md (PbiDialog: state-based, code+title-rij, PbiStatusSelect, geen delete in v1) - docs/scrum4me-story-dialog.md (StoryDialog: state-based, header met status/priority badges, inline activity-log, demo-readonly-fallback, inline-delete-confirm i.p.v. AlertDialog) Beide profielen documenteren expliciet de "Bekende gaps t.o.v. generieke spec" zodat opvolgende PR's de afwijkingen kunnen rechtzetten of bewust kunnen accorderen. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Added pdevelopment docs * docs(plans): add docs-restructure plan for AI-optimized lookup Audit of existing 39 doc files (~10.700 lines) and a phased restructure proposal aimed at minimising the tokens an AI agent has to read to find the right reference. Captures resolved decisions on language (English), ADR template (Nygard default with MADR escape-hatch), index generator (node script), and folder taxonomy. Proposal status — fase 1 to follow. * docs(adr): add ADR scaffolding (templates, README, meta-ADR) Set up docs/adr/ as the canonical home for architecture decisions: - templates/nygard.md — default four-section format (Status, Context, Decision, Consequences) for one-way-door decisions. - templates/madr.md — MADR v4 with YAML front-matter and explicit Considered Options for decisions where rejected alternatives matter. - README.md — naming convention (NNNN-kebab-case), template-selection guidance (Nygard default; MADR for auth, queue mechanics, agent integration), status lifecycle, and ADR roster. - 0000-record-architecture-decisions.md — meta-ADR establishing the practice itself, in Nygard format. Backfilling existing implicit decisions (base-ui-over-radix, float sort_order, demo-user three-layer policy, etc.) is fase 6 of the docs-restructure plan. * feat(docs): add docs index generator + initial INDEX.md scripts/generate-docs-index.mjs walks docs/**/*.md, parses YAML front-matter (or first H1 fallback) and a Nygard-style ## Status section, then writes docs/INDEX.md with grouped tables for ADRs, Specs, Plans (with archive subsection), Patterns, and Other. Pure Node 20 (no external deps); idempotent — running it twice produces byte-identical output. Excludes adr/templates/, the ADR README, INDEX.md itself, and any *_*.md sidecar file. Wire-up: - package.json: docs:index → node scripts/generate-docs-index.mjs Initial run indexed 35 docs across the existing structure; the generated INDEX.md is committed so the table is reviewable in the PR before hooking generation into a pre-commit step. * chore: ignore Obsidian vault and personal sidecar files Add .obsidian/ (Obsidian vault config) and _*.md (personal sidecar notes) to .gitignore so the docs/ tree can serve as canonical source of truth while still being usable as an Obsidian vault for personal authoring. The docs index generator already excludes the same _*.md pattern from INDEX.md. * docs(plans): add PBI bulk-create spec for docs-restructure Machine-parseable spec for an executor that calls the scrum4me MCP (create_pbi → create_story → create_task) to seed the docs-restructure work into the DB. - Section 1 (Context) is the PBI description; serves as task-context via mcp__scrum4me__get_claude_context. - Section 2 lists the 6 resolved decisions (English, MD3+styling merged, solo-paneel merged, .Plans archived, Nygard ADR default, node index script). - Section 3 records what already shipped on this branch so the executor doesn't duplicate the ADR scaffolding or index generator. - Section 4 carries the structured YAML graph: 1 PBI, 8 stories (one per phase), 39 tasks. product_id is REPLACE_ME — fill before running. - YAML validated with PyYAML; field schema sanity-checked. * docs(junk-cleanup): remove stub patterns/test.md * docs(junk-cleanup): archive .Plans/ to docs/plans/archive/ * docs(front-matter): add YAML front-matter to docs/ root * docs(front-matter): add YAML front-matter to patterns/ * docs(front-matter): add YAML front-matter to plans + agent files * docs(index): regenerate INDEX.md after front-matter pass * docs(naming): drop scrum4me- prefix from doc filenames * docs(naming): lowercase API.md and MD3 filenames * docs(naming): rename plan file to kebab-case ASCII * docs(naming): rename middleware.md to proxy.md (next 16) * docs(naming): polish CLAUDE.md doc-index after renames * docs(taxonomy): scaffold topical folders under docs/ * docs(taxonomy): move spec files into docs/specs/ * docs(taxonomy): move design/api/qa/backlog/assets into folders * docs(taxonomy): move agent-instruction-audit into decisions/ * docs(split): break architecture.md into 6 topical files * docs(split): merge solo-paneel-spec into specs/functional.md * docs(split): merge md3-color-scheme into design/styling * docs(trim): extract branch/commit rules into runbook * docs(trim): extract MCP integration into runbook * docs(adr): add 0001-base-ui-over-radix * docs(adr): add 0002-float-sort-order * docs(adr): add 0003-one-branch-per-milestone * docs(adr): add 0004-status-enum-mapping * docs(adr): add 0005-iron-session-over-nextauth * docs(adr): add 0006-demo-user-three-layer-policy * docs(adr): add 0007-claude-question-channel-design * docs(adr): add 0008-agent-instructions-in-claude-md + update README index * docs(index): regenerate after ADR 0001-0008 * docs(glossary): add docs/glossary.md * chore(docs): regenerate INDEX.md in pre-commit hook * docs(readme): link INDEX + glossary + agent instructions * feat(docs): add doc-link checker script * chore(docs): wire docs:check-links and docs npm scripts * ci(docs): block merge on broken doc links * docs(links): fix broken cross-references after restructure --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
104 lines
4.3 KiB
Markdown
104 lines
4.3 KiB
Markdown
---
|
|
title: "QR-pairing via unauth-SSE + pre-auth cookie"
|
|
status: active
|
|
audience: [ai-agent, contributor]
|
|
language: nl
|
|
last_updated: 2026-05-03
|
|
when_to_read: "When working on QR-code login flow or unauth SSE endpoints."
|
|
---
|
|
|
|
# Patroon: QR-pairing via unauth-SSE + pre-auth cookie
|
|
|
|
Het M10 QR-login-mechanisme is herbruikbaar voor elke feature die **realtime-
|
|
feedback wil tussen twee browsers/devices vóórdat de eindgebruiker is
|
|
geauthenticeerd**. De typische vorm:
|
|
|
|
> "Apparaat A start een proces, krijgt een token. Apparaat B (bekend kanaal)
|
|
> bevestigt iets. Apparaat A wil dat realtime weten en daarna iets claimen."
|
|
|
|
Voorbeelden waar dit zou kunnen passen: device-pairing voor 2FA-setup, login-
|
|
op-TV via QR, "claim deze export"-flow, account-overdracht tussen sessies.
|
|
|
|
---
|
|
|
|
## Drie eindpunten
|
|
|
|
| Endpoint | Auth | Doel |
|
|
|---|---|---|
|
|
| `POST /api/.../start` | anon | maakt resource aan, retourneert mobile-secret in body, zet HttpOnly device-token cookie |
|
|
| `GET /api/.../stream/[id]` | cookie | SSE die op LISTEN/NOTIFY wacht op statusverandering |
|
|
| `POST /api/.../claim` | cookie | atomic state-transitie van "approved" → "consumed", wisselt cookie in voor échte sessie |
|
|
|
|
Plus een server-action-laag die door het tweede device wordt aangeroepen na
|
|
het scannen / klikken van een link met fragment-secret.
|
|
|
|
---
|
|
|
|
## Vier security-uitgangspunten
|
|
|
|
1. **Twee gescheiden geheimen** — een voor het kanaal richting het tweede
|
|
device (in QR-fragment), een voor het oorspronkelijke device (in HttpOnly
|
|
cookie). Beide alleen als sha256-hash in DB.
|
|
2. **Geen secret in URL.** Path en querystring lekken naar access logs,
|
|
reverse proxies, observability. Geheimen reizen alleen via:
|
|
- URL-fragment (`#…`) — browsers sturen die niet naar de server
|
|
- HttpOnly cookies — meestal niet gelogd, en alleen leesbaar door server
|
|
- POST-body — niet gelogd standaard
|
|
3. **Atomic consume.** Het claim-endpoint doet één UPDATE met een composite
|
|
WHERE op alle invarianten (status, hash, expiry). PostgreSQL row-locking
|
|
garandeert dat concurrent dubbele claims slechts één caller succes geven.
|
|
4. **Path-scoped cookie.** `Path=/api/.../...` zorgt dat de pre-auth cookie
|
|
alleen naar pairing-routes gaat — niet naar de rest van de app.
|
|
|
|
---
|
|
|
|
## Sjabloon-bestanden
|
|
|
|
Ga voor M10 specifiek? Kopieer en pas aan:
|
|
|
|
- `lib/auth/pairing.ts` — secret/token generators + sha256 + timing-safe verify + expiry helper
|
|
- `lib/auth/pair-cookie.ts` — set/read/clear van Path-scoped HttpOnly cookie
|
|
- `app/api/auth/pair/start/route.ts` — anon POST, rate-limited, sets cookie
|
|
- `app/api/auth/pair/stream/[id]/route.ts` — SSE met cookie-auth, LISTEN op eigen channel
|
|
- `app/api/auth/pair/claim/route.ts` — atomic update + iron-session schrijven
|
|
- `actions/pairing.ts` — Server Actions voor het tweede device
|
|
- `app/(app)/m/pair/pair-confirmation.tsx` — Client island die `location.hash` parseert
|
|
|
|
Voor het tweede device zit de auth meestal al in de bestaande `(app)`-layout
|
|
guard. De Client Component gebruikt `window.location.hash` (niet `useSearchParams`)
|
|
om het secret op te pikken.
|
|
|
|
---
|
|
|
|
## TTL-richtlijn
|
|
|
|
Drie tijden in escalerende volgorde, alle korter dan de reguliere sessie:
|
|
|
|
- **Pending (cookie + DB-rij)** — *kort genoeg dat een verloren cookie/QR
|
|
weinig schade aanricht*. M10: 5 minuten.
|
|
- **Approved (na bevestiging)** — *kort genoeg dat een approved-maar-niet-
|
|
geclaimde pairing niet eindeloos open blijft*. M10: 5 minuten extra.
|
|
- **Resulterende sessie** — *kort genoeg voor publieke apparaten, lang genoeg
|
|
voor een werkdag*. M10: 8 uur, plus `paired: true`-vlag voor toekomstige
|
|
remote-revoke.
|
|
|
|
---
|
|
|
|
## Wanneer dit patroon NIET gebruiken
|
|
|
|
- Wanneer beide kanten al ingelogd zijn — dan is een normaal API-call met
|
|
bestaande sessie eenvoudiger.
|
|
- Wanneer realtime niet kritiek is — een korte poll (`setInterval` op een
|
|
status-endpoint) is simpeler dan een SSE-stream.
|
|
- Wanneer er één centraal apparaat is — gebruik dan een normale sessie; de
|
|
twee-device-dans is alleen nodig om credentials van het ene apparaat naar
|
|
het andere te brengen.
|
|
|
|
---
|
|
|
|
## Referenties
|
|
|
|
- Volledige flow + threat-model: `docs/architecture.md` § QR-pairing flow
|
|
- Endpoint-contract: `docs/api/rest-contract.md` § Auth — QR-pairing
|
|
- LISTEN/NOTIFY-pattern: `app/api/realtime/solo/route.ts` (M8 ST-802) — zelfde
|
|
ReadableStream + heartbeat + hard-close + abort-cleanup, alleen ander channel
|