fix: bypass auth middleware for REST API v1 and agent endpoints

[TerrifiedBug]

Summary

• The Next.js auth middleware was intercepting /api/v1/* and /api/agent/* requests, redirecting them to /login (HTTP 307) before the route handlers could process Bearer token / enrollment token authentication
• Added both paths to the authorized callback bypass in auth.config.ts
• Restored src/middleware.ts (previously deleted) with correct matcher exclusions for api/v1 and api/agent

Test plan

• Deploy and test GET /api/v1/pipelines with a service account Bearer token — should return JSON instead of 307 redirect
• Verify GET /api/v1/nodes, /api/v1/secrets, /api/v1/alerts/rules, /api/v1/audit all work
• Verify agent enrollment endpoint still works
• Verify unauthenticated requests to /api/v1/* return 401 (not 307 redirect)
• Verify web UI pages still redirect to login when not authenticated

[greptile-apps]

Greptile Summary

This PR fixes a regression where Next.js auth middleware was issuing HTTP 307 redirects to /login for /api/v1/* and /api/agent/* requests, breaking Bearer token and enrollment token clients that can't follow HTML redirects. The fix is applied at two layers: the middleware.ts matcher now excludes those path prefixes so the Edge middleware never runs for them, and the authorized callback in auth.config.ts is updated with matching bypass conditions as a defensive fallback (relevant when authConfig is reused in server-side auth() calls via auth.ts).

Key observations:

• Correct approach: Both changed paths have their own auth — /api/v1/* enforces Bearer token validation via authenticateApiKey in api-handler.ts (returns 401 on failure), and /api/agent/* routes verify enrollment/node tokens directly in their handlers.
• Two-layer defense: The matcher exclusion is the primary gate (middleware doesn't run at all); the authorized callback bypass is a redundant-but-safe backstop, consistent with the shared authConfig pattern.
• Matcher breadth: The negative-lookahead pattern (?!...api/v1...) will also exclude any hypothetical future path whose post-slash prefix matches api/v1 (e.g., /api/v10). This is unlikely to be a problem in practice but worth keeping in mind as the API evolves.

Confidence Score: 4/5

• Safe to merge — the bypass is correct, both affected path groups enforce their own authentication, and no unauthenticated access is introduced.
• The changes are minimal, targeted, and well-understood. The underlying API routes already perform proper token validation, so removing the NextAuth session check doesn't open an unguarded path. The matcher regex and the authorized callback are consistent with each other. Minor deduction for the matcher's prefix-based exclusion potentially being slightly over-broad if new /api/v1x routes are added in the future.
• No files require special attention.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    REQ[Incoming Request] --> MATCHER{middleware.ts matcher\nexcludes api/v1, api/agent?}
    MATCHER -- Yes, excluded --> HANDLER[Route Handler]
    MATCHER -- No, runs middleware --> AUTH_CB{authorized callback\nin auth.config.ts}
    AUTH_CB -- isApiV1 or isAgentApi --> HANDLER
    AUTH_CB -- isAuthPage / isHealth / isSetupApi --> HANDLER
    AUTH_CB -- not logged in --> LOGIN[Redirect to /login 307]
    AUTH_CB -- logged in --> HANDLER

    HANDLER --> API_V1{/api/v1/* ?}
    HANDLER --> AGENT{/api/agent/* ?}
    HANDLER --> OTHER[Other authenticated route]

    API_V1 --> BEARER[authenticateApiKey\nBearer token check\n→ 401 if missing/invalid]
    AGENT --> ENROLL_TOKEN[verifyEnrollmentToken\nor node Bearer token\n→ 401 if invalid]

Loading

_{Last reviewed commit: 00ad0c7}