Unauthenticated deep routes recurse `/login` indefinitely; plain HTTP triggers reliably

[Vonng]

Environment

• SILO Console v2.0.0 at b952a1202869b89e5cc7b821a0b5651f74e09d08
• SILO server RELEASE.2026-08-04T00-00-00Z
• Chrome, tested against m.pigsty on 2026-08-05
• Both HTTP and HTTPS currently serve the SPA fallback with 200 OK; an unauthenticated GET /api/v1/session returns 403

Reproduction

1. Use an origin without a Console session. Opening the plain-HTTP origin is a reliable way to reproduce because the HTTPS session is not available there.
2. Open http://m.pigsty/browser (or another protected deep route).
3. Watch the address bar.

Actual result

The relative login path is appended repeatedly:

/browser/login
/browser/login/login
/browser/login/login/login
...

Starting at the root produces /login/login/.... In the live test the path gained hundreds of segments in about two seconds. Access logs have shown roughly 1,300 login segments / 7.8 KiB request targets before nginx eventually returns 414 Request-URI Too Large.

Expected result

An unauthenticated protected route should navigate once to the absolute, base-path-aware login URL. The original protected path should be saved once for the post-login return.

Root cause and regression window

ProtectedRoutes.tsx currently redirects to the relative pathname login. The wildcard protected route then catches the newly nested path again in MainRouter.tsx.

The relative redirect was introduced upstream on 2022-07-20 by cdb1659. It became an active SILO regression on 2026-08-04 in 23ae6e8, which upgraded react-router-dom from 6.30.3 to 7.18.2. In other words: the unsafe relative redirect is old, but the v2.0.0 behavior was introduced on 2026-08-04.

The existing nginx subpath test covers only the exact root URL, not a protected deep link: test-unauthenticated-user.ts.

Acceptance criteria

• Use a single absolute/base-path-aware login destination.
• /, /browser, /tools/metrics, and a nested protected URL do not gain repeated login segments.
• Add unauthenticated deep-link coverage, including the subpath deployment case.
• The saved return path is not overwritten by each login navigation.
• Preferably redirect HTTP to HTTPS at the edge as defense in depth; the client-side redirect must still be correct when an HTTPS session is absent.

[Vonng]

Fixed in v2.1.0 — 8764f5d.

Resolution

ProtectedRoutes.tsx navigated to the relative pathname login, so each redirect appended another segment that the wildcard protected route in MainRouter.tsx immediately re-caught. The fix makes the destination absolute:

-return <Navigate to={{ pathname: `login` }} />;
+return <Navigate to={{ pathname: `/login` }} />;

BrowserRouter is mounted with basename={baseUrl} (MainRouter.tsx:33), so the absolute path is still base-path aware: under a subpath deployment /login resolves to <base>/login, not the server root. localStorage["redirect-path"] is written once, before the single navigation, so the original protected path is no longer overwritten by a chain of redirects.

Coverage

web-app/tests/subpath-nginx/test-unauthenticated-user.ts gained a deep-link case that runs against the nginx subpath deployment (MINIO_BROWSER_REDIRECT_URL = /console/subpath):

test("Deep routes redirect once to Login Page", async (t) => {
  await t.navigateTo(`${appBaseUrl}/browser`)
    .expect(elements.loginButton.exists).ok()
    .expect(getRedirectState()).eql({
      pathname: "/console/subpath/login",
      redirectPath: "/browser",
    });
});

It asserts both properties that were broken: the landing URL has exactly one login segment under the deployment base, and the stored return path is the original deep route.

Acceptance criteria

• Single absolute, base-path-aware login destination
• /, /browser, and nested protected URLs no longer accumulate login segments
• Unauthenticated deep-link coverage, including the subpath deployment case
• Saved return path is not overwritten by each login navigation

The HTTP-to-HTTPS edge redirect remains a deployment-side recommendation rather than a console change; the client-side redirect is now correct on its own when no HTTPS session exists, which was the actual defect.

Closing as fixed in v2.1.0.