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. 1.Autentizace: existuje validní uživatelská session?
  2. 2.Kontext organizace: má uživatel membership a je vybraná aktivní org?
  3. 3.Vlastnictví zdroje: patří požadovaný zdroj do aktivní org?
  4. 4.RBAC: dovoluje role požadovanou akci?
  5. 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)