Skip to main content

How a visitor becomes an authorized dashboard user

Cookie check → credentials + optional 2FA → a live capability fetch from GET /auth/session-context → gated entry into feature areas. Every gate fails closed: a missing, denied, or unreadable session sends the user back out, never through.

Legend: teal = authorized destination · dashed red = dead end, routes back to Login · gold = degraded/retry. Both dashed "Redirect to Login" nodes are the same destination as the Login page at the top — drawn twice to avoid routing an edge across the whole diagram.

Reading notes​

  • Cookies are a bootstrap, not a decision. proxy.ts only checks whether the auth cookie exists, to decide which page to render. It never authorizes anything — that happens exclusively via the live session-context fetch.
  • Live always wins. Once session-context returns, its capabilities map overrides any bootstrap value from cookies or the persisted Redux snapshot — including overriding a persisted true down to false.
  • Two independent capability gates stand between login and the dashboard: risk_dashboard_login (can this user open the dashboard at all) and then, separately, whether they hold any section capability (otherwise they're logged in but have nothing to see).
  • Degraded ≠ denied. A 5xx or timeout from session-context shows a retry surface rather than kicking the user out — but every high-risk capability fails closed until a live response actually arrives.
  • Each of the six sidebar areas re-runs its own capability check on entry (CapabilityGuard / SessionCapabilityPageShell) — reaching Dashboard Home doesn't imply access to everything under it.

Full detail on the mechanism behind this diagram: Auth & session.

Derived from proxy.ts, modules/auth/SessionContextProvider.tsx, modules/auth/riskDashboardAccess.tsx, modules/auth/pages/loginUI/useLogin.tsx, and layout/DashboardSidebar/DashboardSidebar.tsx.