Dokumentace
Centrum nápovědyAplikaceGuard logika
docs/cs/03-application/guard-logic.md
Guard logika (Auth, Org, RBAC, Subscription)
Tento dokument definuje routing a model “feature guardů” pro App Router strukturu OPORA.
Pořadí vyhodnocení guardů (invariant)
Pro všechny /app/* routy a akce:
- 1.Autentizace: existuje validní uživatelská session?
- 2.Kontext organizace: má uživatel membership a je vybraná aktivní org?
- 3.Vlastnictví zdroje: patří požadovaný zdroj do aktivní org?
- 4.RBAC: dovoluje role požadovanou akci?
- 5.Subscription gating: dovoluje plán organizace danou funkci?
Toto pořadí zajišťuje správnost, minimalizuje information leakage a sjednocuje chování při zamítnutí.
Invarianty struktury rout
- Marketing je veřejný na
/…. - Aplikace je pod
/app/*a autentizace je výchozí požadavek. - Post-auth routing je centralizovaný v
/post-auth. - Projekty jsou kanonické; editace/výpočet probíhá na
/app/projects/[projectId]/edit.
Logika `/post-auth`
/post-auth je jediný decision point po přihlášení/potvrzení:
- pokud nejsou žádné membership → redirect
/app/onboarding - pokud existuje více org a není aktivní volba → redirect
/app/org-select - jinak → redirect
/app/projects
RBAC model (high-level)
RBAC je tenant-scoped:
- role a oprávnění se vyhodnocují v rámci aktivní organizace
- oprávnění gateují akce (write/export/member management), ne pouhou existenci dat
Subscription gating model (high-level)
- gating se vynucuje na feature surface
- typické gating stránky:
/app/subscription-required/app/upgrade-required- export gating se vyhodnocuje na:
/app/projects/[projectId]/results
Failure chování (UX invarianty)
- neautentizovaný přístup na
/app/*→ redirect na/sign-in?redirect=... - zakázaná akce (RBAC) →
/app/access-denied - plan gating →
/app/upgrade-required(nebo/app/subscription-required) - not found nebo not owned → chovat se jako
NOT_FOUND(neprozrazovat existenci cross-tenant)