Auth middleware misclassifies routes below an ASGI root path

[RaresKeY]

Prerequisites

• I searched open issues and pull requests and did not find an existing report for this mounted-path middleware mismatch.
• I reproduced this against the current dev branch.
• I checked the installed Starlette and Uvicorn path behavior rather than assuming proxy behavior.

Install Method

Manual Python install (pip / venv)

Operating System

Linux

Steps to Reproduce

1. Run current dev through an ASGI server with a non-empty root_path.
2. Send requests through that mount prefix to an intended public auth/setup route and to a protected API route.
3. Compare the path used by AuthMiddleware with the application-relative path Starlette uses to match the route.

The specific prefix that demonstrates the security-boundary failure is intentionally omitted from the public issue.

Expected Behaviour

Middleware policy and Starlette routing should evaluate the same application-relative path. Public setup/auth routes should retain their intended exemption, while protected routes should remain protected regardless of the deployment prefix. Unauthenticated API requests should continue to receive an API response rather than a browser redirect.

Actual Behaviour

AuthMiddleware currently evaluates the prefixed URL path while Starlette removes root_path before route matching. Mounted deployments can therefore miss intended public-route exemptions, misclassify API failures as browser navigation, or apply an exemption based on the deployment prefix rather than the protected application route.

This does not affect the default empty-root_path configuration.

Logs / Screenshots

Reproduced with ASGI scopes matching the installed Uvicorn and Starlette behavior. The sensitive prefix and copy-paste bypass recipe are not included here.

Model / Backend (if relevant)

Not relevant.

Are you willing to submit a fix?

Yes — I can open a PR

Additional Information

The focused fix should derive the application-relative route path from the ASGI scope once at the middleware boundary and use it for auth exemptions, first-run setup handling, API-versus-browser unauthorized responses, and bearer route-capability checks where present.

Acceptance criteria:

• Middleware policy matches Starlette route-path semantics for ordinary, trailing-slash, and mismatched root paths.
• A deployment prefix cannot broaden an auth exemption.
• Setup and unauthenticated API behavior works below a non-empty ASGI root path.
• The default empty-root deployment remains unchanged.
• Focused real-middleware regressions pass against current dev.

Related: parent stabilization tracker #5674 and bearer-token capability tracker #3149.