fix: respect auth_disabled in fe middleware for local dev

[nmgarza5]

Description

This was causing redirects when developing EE features locally.

How Has This Been Tested?

local testing

Additional Options

• [Optional] Override Linear Check

---

Summary by cubic

Updated frontend middleware to respect the auth_disabled flag. When auth is disabled, protected routes no longer redirect in local development.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
internal-search	Ready	Preview	Comment	Oct 28, 2025 3:19am

[greptile-apps]

Greptile Overview

Greptile Summary

Added support for respecting the auth_disabled flag in the frontend middleware to prevent unwanted authentication redirects during local development of Enterprise Edition features.

Key changes:

• Imported getAuthDisabledSS helper function to check if authentication is disabled
• Added isAuthDisabled check to the protected route validation logic
• Protected routes now skip authentication checks when auth is disabled

Issues found:

• Import statement uses relative path instead of absolute path with @ prefix (violates web/STANDARDS.md)

Confidence Score: 4/5

• This PR is safe to merge with minimal risk after addressing the style issue
• The logic change is straightforward and correctly implements the auth_disabled check. The getAuthDisabledSS function already exists and is well-tested from PR #5931. Only concern is a minor style guide violation (relative vs absolute imports), which doesn't affect functionality
• No files require special attention beyond the style fix

Important Files Changed

File Analysis

Filename	Score	Overview
web/src/middleware.ts	4/5	Added auth_disabled check to middleware to prevent redirects during local development; import uses relative path instead of absolute path with @ prefix

Sequence Diagram

sequenceDiagram
    participant Client
    participant Middleware
    participant AuthAPI as Auth API (/auth/type)
    participant LoginPage as /auth/login
    participant ProtectedRoute as Protected Route

    Client->>Middleware: Request protected route (e.g., /chat)
    Middleware->>Middleware: Check if route is protected
    Middleware->>Middleware: Check if route is public
    
    alt Auth check needed
        Middleware->>AuthAPI: getAuthDisabledSS() -> GET /auth/type
        AuthAPI-->>Middleware: {auth_type: "disabled" | "basic" | "oidc" | ...}
        
        alt Auth is disabled
            Middleware->>ProtectedRoute: Allow access (skip cookie check)
            ProtectedRoute-->>Client: Return protected content
        else Auth is enabled
            Middleware->>Middleware: Check for auth cookie
            
            alt Cookie exists
                Middleware->>ProtectedRoute: Allow access
                ProtectedRoute-->>Client: Return protected content
            else No cookie
                Middleware->>LoginPage: Redirect to /auth/login?next=/chat
                LoginPage-->>Client: Return login page
            end
        end
    else Public route or not protected
        Middleware->>ProtectedRoute: Allow access
        ProtectedRoute-->>Client: Return content
    end

Loading

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (all 1 issues)

Understand the root cause of the following 1 issues and fix them.


<file name="web/src/middleware.ts">

<violation number="1" location="web/src/middleware.ts:63">
Awaiting getAuthDisabledSS here means any network error or non-2xx from /auth/type will throw, crashing the middleware and returning 500 for every protected request. Please default to requiring auth if the lookup fails so we retain previous behavior.</violation>
</file>

_{React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.}