lib/auth-guard

Page reload on an authentication wall that moves under a live page.

When basic auth is enabled on the server or proxy, or a session expires, the stream either dead-stalls or keeps streaming while every API call returns 401. Either way only a fresh document can re-present the login, so any observed same-origin 401 reloads the page once. The server's own Bearer verdicts are exempt: a reload cannot change them. installAuthGuard wraps window.fetch for the whole page (cores and dashboards share it) and publishes window.__selkiesAuthProbe, which socket close handlers call so a WebSocket dropped by the auth wall triggers the same reload instead of silently retrying.

Reloads are chained through a stamp that survives them: a deployment that serves the page without auth but keeps API routes permanently 401 (an expired app cookie, split forward-auth) would otherwise reload forever. Two reloads inside the window still re-present an auth wall when the document itself is challenged, since that path self-terminates, while a permanent API-only 401 stops reloading. The stamp lives in sessionStorage, falling back to history.state where storage is blocked (private modes, cookie-blocked embeds) because that rides the session-history entry through location.reload().

Functions

installAuthGuard()

function installAuthGuard(): void;

Defined in: lib/auth-guard.js:43

Installs the fetch wrapper and the probe once per page.

The server's token verdicts (secure mode: a route wanting a session or master token) name the Bearer scheme in WWW-Authenticate; a reload would re-present the very same token, so those are left to the caller (the file-upload error, the mode-switch master-token prompt).

Returns

void

sameOrigin()

function sameOrigin(input): boolean;

Defined in: lib/auth-guard.js:94

Whether a request targets this origin; a third-party API's 401 must not reload the page.

Parameters

Returns

boolean