🎨 Pattern: What pattern should Platform Elements use for route protecti...

Date: 2026-03-25
Time: 12:09:09 UTC
Session: gspace1-268.9
Agent: angular
Confidence: 91%
Status: ✅ Documented

📋 Decision Context

Question:

What pattern should Platform Elements use for route protection in standalone deployed platforms?

Task: S268.2: Platform Elements Phase 1 — Route guard implementation

🎯 Decision Made

Chosen:

Declarative HTML attribute guards on platform-route: guard='authenticated' for login-required routes, guard='admin' for role-based routes, public attribute for always-accessible routes. Router checks window.platformAuthManager before showing guarded routes and redirects to login-redirect path on failure.

Options Considered:

1. Angular-style canActivate functions (too complex for declarative HTML)
2. JWT claim-based guards (requires parsing JWT, fragile)
3. Backend-side route protection only (doesn't hide UI, bad UX)
4. No guards, rely on API-level auth only (security risk — users see unauthorized data)

💭 Reasoning

The guard system must be declarative (AI generates it as HTML attributes) and must work without JavaScript logic in the generated output. Three guard levels cover all CRUD platform cases: (1) public — login page, landing page, (2) authenticated — any logged-in user, (3) role-based — admin settings, manager dashboards. The router hides guarded routes from the nav bar when the user lacks access (no 'Settings' tab for non-admins). Redirect to login happens automatically when accessing a guarded route while unauthenticated. This is intentionally simpler than Angular's CanActivate/CanDeactivate/Resolve — those patterns are overkill for declarative CRUD platforms. If a platform needs complex guard logic, it should export to Angular.

📁 Files Involved

• libs/libs-structural/platform-elements/src/lib/elements/platform-router.ts

🔗 Related

• Decision ID: dev_1774440549102_7dratjp
• Session: 268
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation