🐛 Bugfix: How should the shared auth interceptor handle 401 redirects ...

Date: 2026-02-21
Time: 17:25:36 UTC
Session: gspace1-131.8
Agent: angular
Confidence: 99%
Status: ✅ Documented

📋 Decision Context

Question:

How should the shared auth interceptor handle 401 redirects when different apps have different (or no) login routes?

Task: Not specified

🎯 Decision Made

Chosen:

Use injectable tokens so each app configures its redirect behavior

Options Considered:

1. Hardcode '/auth/login' in the interceptor (current, broken)
2. Make each app create its own interceptor (code duplication)
3. Use injectable tokens so each app configures its redirect behavior

💭 Reasoning

Bug: auth.interceptor.ts hardcoded router.navigate(['/auth/login']) on 401. gograb-ai has no /auth/login route, so Angular fell through to /dashboard with ?sessionExpired=true, silently breaking the app. Fix: Created AUTH_LOGIN_ROUTE (default '/login'), AUTH_REDIRECT_STRATEGY ('redirect' | 'event'), and AUTH_SESSION_EXPIRED$ (Subject) tokens in @auth-ui. Each app provides its own config: gograb-space='/auth/login', gograb-admin/gograb-dev/space-admin='/login', gograb-ai=strategy:'event' (no redirect, emits observable). Rule for future agents: NEVER hardcode route paths in shared libraries. Always use injectable tokens that each app can override.

📁 Files Involved

• No files specified

🔗 Related

• Decision ID: dev_1771694736612_46uvy7e
• Session: 131
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation