Login page enters infinite redirect loop (/auth/sign-in?next=… → HTTP 414), sign-in form never renders (authenticated mode)

[vfoschi]

Summary

In authenticated mode, the sign-in page enters an infinite client-side redirect loop and never renders the login form, so no one can log into the web UI. The next query param keeps nesting on each redirect until the URL grows to thousands of characters and requests start returning HTTP 414 URI Too Long.

Environment

• Self-hosted Docker, ghcr.io/paperclipinc/paperclip, single replica, external Postgres (also reproduced with embedded Postgres).
• deploymentMode: authenticated, exposure: private, auth.baseUrlMode: explicit with a publicBaseUrl, behind an HTTPS reverse proxy.
• Reproduced on a clean browser profile (no cookies/localStorage) with headless Chromium (Playwright) — so it is not stale client state.

Affected vs working builds

Same DB, same env/config — only the image changes the behavior:

• ✅ Works (form renders, lands on /auth?next=/): image revision b57c11d7.
• ❌ Broken: revision e02ab855 and every later build incl. current :latest (e.g. 729c2f7f).

Steps to reproduce

1. Deploy in authenticated + private mode behind an HTTPS reverse proxy.
2. Open the base URL in a fresh browser (no session).
3. Redirected to /auth/sign-in?next=%2F, which then redirects to /auth/sign-in?next=<url-encoded previous> recursively, forever.

Observed

• Anonymous requests during the loop: GET /api/auth/get-session → 401, GET /api/companies → 403 (Board access required), GET /api/adapters → 403. The SPA reacts by redirecting to sign-in instead of rendering the form.
• The sign-in route appears to apply the "redirect unauthenticated → sign-in?next=current" guard to itself, so next nests indefinitely; eventually the server returns HTTP 414.
• Page body stays near-empty; no input[type=password] is ever mounted. No uncaught JS exceptions.
• On working revision b57c11d7 the same flow lands on /auth?next=/ and renders the form (the route path changed from /auth to /auth/sign-in between the working and broken builds — likely where the regression sits).

Expected

/auth/sign-in should render the login form for anonymous users and must not apply the unauthenticated-redirect guard to the sign-in route itself.

Extra

Happy to share the minimal Playwright repro script and the full network trace.

[stubbi]

Thanks for this — the bisect down to the exact image revision and the clean-profile Playwright repro made this straightforward to confirm. Your diagnosis was right, including the guess that the /auth → /auth/sign-in route change is where it sits.

Root cause

Commit 8695d8854 ("fix(cloud): sign-out and unauthenticated redirects leave the SPA to the gateway auth pages") changed one line in ui/src/App.tsx:

-        <Route path="auth" element={<AuthPage />} />
+        <Route path="auth" element={<CloudAuthRedirect />} />

CloudAuthRedirect unconditionally does window.location.replace("/auth/sign-in?next=…"). That is correct on our hosted deployment, where /auth/* is served by the gateway and never reaches the SPA at all. It is wrong everywhere else, because:

1. There is no <Route path="auth/sign-in"> in the SPA — /auth is the only auth route.
2. So on a self-hosted deploy, /auth/sign-in falls through to the catch-all, which is wrapped in CloudAccessGate.
3. CloudAccessGate, seeing a definitive unauthenticated session, runs:

   const next = encodeURIComponent(`${location.pathname}${location.search}`);
   window.location.replace(`/auth/sign-in?next=${next}`);

   with no exemption for the sign-in route itself.
4. That re-enters step 2 with next one level deeper each pass. The URL grows until the server answers 414.

AuthPage itself was never deleted — it is still sitting in ui/src/pages/Auth.tsx, just no longer routed. That is why the form never mounts and why you see no JS exception: nothing is broken, the component simply is not reachable any more.

Scope

This is specific to the paperclipinc/paperclip fork image you are running. Upstream paperclipai/paperclip still has <Route path="auth" element={<AuthPage />} /> and is unaffected. It also does not affect our own hosted site, where the gateway owns /auth/* — which is exactly why it went unnoticed for two weeks. Apologies; you were the one paying for that blind spot.

Two behaviours need to be re-separated, and I am working on the fix now:

• /auth must render AuthPage when the SPA is the thing serving auth (self-hosted authenticated mode), and only redirect when a gateway is actually in front of it.
• CloudAccessGate must never apply its unauthenticated-redirect to the sign-in route itself, regardless of deployment mode — that guard is missing today and is what turns a wrong route into an infinite loop rather than a 404.

I will link the PR here.

Meanwhile

If you need to unblock before that lands, pinning to b57c11d7 is the right call — that is the last revision with AuthPage still routed, and nothing else in the auth path changed between then and now.

I would still like the Playwright script if you are happy to share it. There is clearly no regression test covering "anonymous user can reach the sign-in form in authenticated mode", and yours would be a good basis for one.

[stubbi]

Fix is up: #319.

It does the two things described above — CloudAccessGate no longer redirects when the visitor is already on an /auth/* route (that guard is general, so another auth subroute cannot reintroduce the loop), and /auth/sign-in is routed to the AuthPage component that was left unrouted, so the form actually mounts once the loop stops.

Two regression tests cover the loop itself. What they do not cover is "the form mounts end to end on a self-hosted authenticated deploy" — that needs a real deployment, and the absence of exactly that test is why this shipped in the first place. If you are still willing to share the Playwright script, I would like to land it in the e2e suite as a follow-up so this cannot regress silently again.