The right Core key always signs in; the audit actor is caller-declared

Author: SaladDay

apps/web/e2e/access.spec.ts

@@ -32,6 +32,9 @@ test("signs in with the Core key, keeps it out of the browser, and signs out and
   await page.getByRole("button", { name: "Sign out" }).click();
   for (let attempt = 0; attempt < 3; attempt++) await signIn(page, "not-the-core-key");
   await expect(page.getByRole("alert")).toHaveText("Too many attempts. Try again in 30 seconds.");
+  // Failed attempts never lock out the right key.
+  await signIn(page, FIXTURE_CORE_KEY);
+  await expect(page.getByRole("heading", { name: "Overview", level: 1 })).toBeVisible();
   expect(await browserStorage(page)).not.toContain(FIXTURE_CORE_KEY);
 });
 

apps/web/e2e/fixture-console.mjs

@@ -84,16 +84,17 @@ function authError(response, status, message, headers = {}) {
   send(response, status, { error: message }, headers);
 }
 
-/** Sign-in with the Core key: a wrong key is refused, and repeated wrong keys lock sign-in for a while. */
+/** Sign-in with the Core key, as the console server does it: the key is compared first, so the right key
+ * always signs in; only wrong keys count, and repeated wrong keys are refused for a while. */
 async function login(request, response) {
   const auth = state.auth;
   if (!request.headers["content-type"]?.startsWith("application/json")) return authError(response, 415, "Use application/json");
   let input;
   try { input = await body(request); } catch { return authError(response, 400, "Invalid authentication request"); }
   if (typeof input?.core_key !== "string" || !input.core_key) return authError(response, 400, "Invalid authentication request");
-  const wait = Math.ceil((auth.lockedUntil - Date.now()) / 1000);
-  if (wait > 0) return authError(response, 429, "Too many authentication attempts", { "retry-after": String(wait) });
   if (input.core_key !== CORE_KEY) {
+    const wait = Math.ceil((auth.lockedUntil - Date.now()) / 1000);
+    if (wait > 0) return authError(response, 429, "Too many authentication attempts", { "retry-after": String(wait) });
     auth.failures += 1;
     if (auth.failures < LOCKOUT_AFTER) return authError(response, 401, "Invalid Core key");
     auth.lockedUntil = Date.now() + LOCKOUT_SECONDS * 1000;

docs/web/architecture.md

@@ -35,7 +35,7 @@ The console authenticates the browser, checks the request origin and forwards on
 allowed management routes. It replaces browser authorization and actor headers,
 strips browser cookies, and supplies its server-side deployment credential. Core
 rejects application keys on management routes and deployment credentials on `/v1`.
-The forwarded audit actor label is always `console` for console operations (operator scripts calling Core with the Core key directly leave it empty); it is display only, not Core authorization.
+The audit actor label is declared by the caller and is display only, never Core authorization: the console server declares `console`, and operator scripts calling Core with the Core key directly leave it empty.
 
 Node and daemon connections use `/api/v1` with their own credentials. The reverse
 proxy sends them directly to Core; the console never forwards them, and they do not

docs/web/core-connection.md

@@ -49,7 +49,7 @@ configuration to an authenticated browser.
 Use TLS for remote browser access and loopback listeners for local development.
 Preserve host/origin checks and the management route allowlist. Browser authorization,
 cookies and actor headers are replaced or removed before forwarding to Core.
-A browser cannot choose the audit actor label the service reports: console operations always show as `console`. Keep deployment, application, node and provider credentials
+A browser cannot choose the audit actor label the service reports: the console server declares `console`. The label is caller-declared and display only. Keep deployment, application, node and provider credentials
 out of `VITE_*`, browser storage, source files, URLs and logs.
 
 ## Projects and application keys