M12 / ST-1110: Demo gebruiker read-only (#17 )

* feat(ST-1110.3): add proxy.ts demo-guard for non-GET API routes

* feat(ST-1110.3+4): demo-guard proxy + block demo in QR-pairing

- proxy.ts: gebruik unsealData ipv getIronSession (middleware-compatibel)
- pair/start: isDemo-check via cookies() guard
- pair/claim: check pairing.user.is_demo na DB-read; 403 + clearPairCookie

* feat(ST-1110.5): unify demo write-button pattern to disabled+tooltip

Convert all !isDemo && <Button> patterns to <DemoTooltip show={isDemo}>
<Button disabled={isDemo}> so demo visitors see app capabilities.
Affects: pbi-list, story-panel, story-dialog, task-list, sprint-backlog,
token-manager, product-list, activate-product-button, leave-product-button,
settings page.

* test(ST-1110.6): proxy demo-guard coverage — 403 for demo+non-GET on /api/*

* docs(ST-1110.7): document three-layer demo-readonly policy and mirror plan

2026-04-29 18:44:14 +02:00

2.9 KiB

Raw Blame History

Plan: ST-1110 — Demo gebruiker read-only

Context

Demo-gebruikers (is_demo=true in DB) mogen de app niet muteren. Vóór ST-1110 was de beveiliging gemengd en inconsistent: sommige routes hadden een isDemo-check, sommige niet; UI-patronen waren inconsistent (deels verborgen, deels disabled+toast).

Audit resultaten (ST-1110.1)

Gevonden beveiligingsgaten vóór ST-1110:

/api/auth/pair/start en /api/auth/pair/claim: geen isDemo-check
/api/todos, /api/stories, /api/tasks e.a.: hadden isDemo-check in actie, maar geen middleware-laag
UI: 24+ locaties gemengd patroon (!isDemo && <Button> of disabled+toast)

Gekozen aanpak (ST-1110.2)

Drie-laagse bescherming:

Middleware-guard in proxy.ts (defense in depth voor toekomstige routes)
Per-route guards in Server Actions en Route Handlers
UI-laag: uniform disabled + DemoTooltip

M11-antwoorden

ST-1110.4 — QR-pairing voor demo-gebruiker

Vraag: Mag een demo-gebruiker een QR-pairing starten en claimen?
Opties:

Blokken — voeg isDemo-check toe in pair/start en pair/claim, demo krijgt 403
Openhouden — geen wijziging; demo kan pair-flow starten maar approve faalt toch

Antwoord (2026-04-29): Blokken

Implementatie:

pair/start: getIronSession(await cookies(), sessionOptions) → 403 als session.isDemo
pair/claim: check pairing.user?.is_demo na DB-read → 403 + clearPairCookie()
proxy.ts DEMO_WRITE_ALLOWLIST bevat pair-paden NIET

ST-1110.5 — Write-knoppen voor demo-gebruiker

Vraag: Hoe write-knoppen tonen aan demo-gebruikers?
Opties:

Verbergen — {!isDemo && <Button />}, minder visuele clutter
Disabled + tooltip "Niet beschikbaar in demo-modus" — bezoeker ziet wat de app kan

Antwoord (2026-04-29): Disabled + tooltip

Implementatie: Alle !isDemo && <Button> patronen omgezet naar <DemoTooltip show={isDemo}><Button disabled={isDemo}>.

Bestanden gewijzigd

Task	Commits	Bestanden
ST-1110.3	`feat(ST-1110.3)`	`proxy.ts`
ST-1110.3+4	`feat(ST-1110.3+4)`	`proxy.ts`, `app/api/auth/pair/start/route.ts`, `app/api/auth/pair/claim/route.ts`
ST-1110.5	`feat(ST-1110.5)`	12 component/pagina-bestanden
ST-1110.5 tests	`test(ST-1110.5)`	`__tests__/api/pair-claim.test.ts`, `__tests__/api/pair-start.test.ts`
ST-1110.6	`test(ST-1110.6)`	`__tests__/proxy/demo-guard.test.ts`
ST-1110.7	`docs(ST-1110.7)`	`docs/scrum4me-architecture.md`, dit bestand

Aandachtspunten toekomstige stories

Elke nieuwe write-route (Server Action of Route Handler) moet session.isDemo checken
De middleware-guard valt terug als defense in depth — niet als enige bescherming
Drag-and-drop handles blijven verborgen voor demo ({!isDemo && <span {...listeners} />})
Nieuwe write-knoppen in UI: <DemoTooltip show={isDemo}><Button disabled={isDemo}>

2.9 KiB Raw Blame History