@openparachute/hub 0.7.7-rc.6 → 0.7.7-rc.8

package/src/hub-server.ts

@@ -114,6 +114,13 @@
  *                                                 (hub#473; reached after a correct
  *                                                 password for a 2FA-enrolled user)
  *   /logout                       (POST)       → end admin session
+ *   /account/session               (GET)        → same-origin boot oracle {signed_in,
+ *                                                 csrf,...} (hub-parity P1); cookie-gated,
+ *                                                 NOT Bearer — mounted ABOVE the
+ *                                                 force-change-password gate below (a pure
+ *                                                 state oracle, so a pre-rotation user can
+ *                                                 still read it to drive the rotation
+ *                                                 ceremony itself)
  *   /account/change-password      (GET + POST) → user self-service change-password
  *                                                 (force-redirect target for users
  *                                                 with password_changed=false; also
@@ -122,7 +129,8 @@
  *                                                 + the per-vault proxy is hard-gated
  *                                                 per-request on password_changed===true
  *                                                 (forceChangePasswordGate); only this
- *                                                 route and /logout stay reachable
+ *                                                 route, /logout, and /account/session
+ *                                                 (P1, also above the gate) stay reachable
  *                                                 pre-rotation.
  *   /account/token                (POST)       → cookie→account-bearer mint (App
  *                                                 campaign Phase 2 H1): session cookie →
@@ -190,6 +198,7 @@ import {
   handleAccountSetVaultCaps,
   requireAnyScope,
 } from "./account-api.ts";
+import { type AccountSessionDeps, handleAccountSession } from "./account-session.ts";
 import { handleAccountSetupGet, handleAccountSetupPost } from "./account-setup.ts";
 import { handleAccountToken } from "./account-token.ts";
 import { handleAccountVaultAdminTokenPost } from "./account-vault-admin-token.ts";
@@ -2853,7 +2862,13 @@ export function hubFetch(
         if (req.method === "OPTIONS") {
           return new Response(null, { status: 204, headers: corsHeaders });
         }
-        const res = handleAccountCapabilities(req, { issuer: oauthDeps(req).issuer });
+        if (!getDb) {
+          return new Response('{"error":"account descriptor unavailable: db not configured"}', {
+            status: 503,
+            headers: { "content-type": "application/json", ...corsHeaders },
+          });
+        }
+        const res = handleAccountCapabilities(req, { db: getDb(), issuer: oauthDeps(req).issuer });
         const merged = new Headers(res.headers);
         for (const [k, v] of Object.entries(corsHeaders)) merged.set(k, v);
         return new Response(res.body, { status: res.status, headers: merged });
@@ -3746,6 +3761,20 @@ export function hubFetch(
         return new Response("method not allowed", { status: 405 });
       }
 
+      // /account/session — the same-origin boot oracle (hub-parity P1). A
+      // PURE STATE ORACLE, not a mutating surface, so it is mounted ABOVE the
+      // force-change-password gate immediately below: a pre-rotation user
+      // must still be able to read `{signed_in, csrf}` to drive the rotation
+      // ceremony itself, rather than get walled off before it can even ask.
+      // `/account/token` (below the gate) stays gated — a pre-rotation user
+      // hits its 403 `force_change_password` there instead. See
+      // `account-session.ts`.
+      if (pathname === "/account/session") {
+        if (!getDb) return dbNotConfigured();
+        const sessionDeps: AccountSessionDeps = { db: getDb() };
+        return handleAccountSession(req, sessionDeps);
+      }
+
       // Per-request force-change-password gate (P0-1 / hub#469). CHOKE POINT 1:
       // every `/account/*` route BELOW this line is gated. `/logout` and
       // `/account/change-password` (the rotation/exit path) ran above and already
@@ -3937,9 +3966,10 @@ export function hubFetch(
         }
         return new Response("method not allowed", { status: 405 });
       }
-      // GET /account (Bearer) — account bootstrap {account_id,email,door}. Only
-      // intercepts when an Authorization header is present, so the cookie-authed
-      // HTML account home at `/account`/`/account/` below stays unaffected.
+      // GET /account (Bearer) — account bootstrap {id,email,door} (the
+      // door-contract's AccountBootstrap). Only intercepts when an
+      // Authorization header is present, so the cookie-authed HTML account
+      // home at `/account`/`/account/` below stays unaffected.
       if (
         (pathname === "/account" || pathname === "/account/") &&
         req.headers.get("authorization")

package/src/hub-settings.ts

@@ -122,7 +122,21 @@ export type HubSettingKey =
   // wizard funnel + pre-admin 503 lockout run BEFORE this redirect, so a
   // not-yet-set-up hub still lands on setup, not a surface that can't work
   // yet.
-  | "root_redirect";
+  | "root_redirect"
+  // hub-parity P2 (Q2): the RAW token of the newest PUBLIC (multi-use,
+  // `max_uses > 1`) invite — persisted so `GET /.well-known/parachute-account`
+  // can advertise `signup_path` without being able to reconstruct it from the
+  // `invites` table (which stores only `sha256(token)`, see invites.ts's
+  // module doc). Written by `api-invites.ts`'s `handleCreateInvite` right
+  // after a successful multi-use `issueInvite`; read (and lazily cleared once
+  // stale) by `invites.ts`'s `activePublicSignupPath`.
+  //
+  // This does NOT weaken the hash-only posture of single-use friend invites
+  // (`max_uses === 1`, the default) — those NEVER write this row. A
+  // multi-use link is, by construction, the operator's deliberately PUBLIC
+  // signup page (minted to broadcast), so persisting its raw token is no
+  // more sensitive than the link itself already being handed out widely.
+  | "public_signup_token";
 
 export type SetupExposeMode = "localhost" | "tailnet" | "public";
 

package/src/invites.ts

@@ -57,6 +57,7 @@
  */
 import type { Database } from "bun:sqlite";
 import { createHash, randomBytes } from "node:crypto";
+import { deleteSetting, getSetting } from "./hub-settings.ts";
 
 /** Default invite lifetime — long enough to deliver out-of-band (no email), short enough to bound a leaked link. */
 export const DEFAULT_INVITE_TTL_SECONDS = 7 * 24 * 60 * 60;
@@ -502,3 +503,44 @@ export function revokeInvitesForVault(
     .run(now.toISOString(), vaultName);
   return Number(res.changes);
 }
+
+/**
+ * Q2 (hub-parity P2) — the account descriptor's conditional `signup_path`.
+ * The hub cannot derive a redemption URL from the `invites` table (only
+ * `sha256(token)` is stored, never the raw value — see the module doc), so
+ * this reads back the ONE raw token persisted at mint time for a
+ * deliberately PUBLIC (multi-use) invite (`api-invites.ts`'s
+ * `handleCreateInvite`, which writes `hub_settings.public_signup_token`
+ * after `issueInvite` when `maxUses > 1`) and re-validates it's still live.
+ *
+ * Returns `/account/setup/<token>` when the persisted invite is still
+ * `"pending"`, still multi-use (`maxUses > 1`), AND provisioning
+ * (`provisionVault` — each redeemer gets their own new vault); `null` on ANY
+ * miss (never set, redeemed, revoked, exhausted, expired, or a non-provisioning
+ * shared-vault link) — and lazily clears the stale setting in that case. No
+ * separate revoke/exhaust/expire hook is needed: `inviteStatus` already derives
+ * all four terminal states from the invite's own columns, so every miss flows
+ * through this one status check.
+ *
+ * The `maxUses > 1` AND `provisionVault` re-checks are defense-in-depth mirrors
+ * of `handleCreateInvite`'s write condition (which only persists for a
+ * multi-use provisioning link): even a hand-edited settings row pointing at a
+ * single-use OR a shared-vault (`provision_vault=false`) invite must never be
+ * advertised as public signup — a shared-vault link would leak team-vault write
+ * on the anonymous, wildcard-CORS descriptor.
+ */
+export function activePublicSignupPath(db: Database, now: Date = new Date()): string | null {
+  const raw = getSetting(db, "public_signup_token");
+  if (!raw) return null;
+  const invite = findInviteByRawToken(db, raw);
+  if (
+    !invite ||
+    inviteStatus(invite, now) !== "pending" ||
+    invite.maxUses <= 1 ||
+    !invite.provisionVault
+  ) {
+    deleteSetting(db, "public_signup_token");
+    return null;
+  }
+  return `/account/setup/${encodeURIComponent(raw)}`;
+}

package/src/sessions.ts

@@ -4,12 +4,21 @@
  * with that cookie skip the login form and go straight to consent.
  *
  * Stored in `sessions` (one row per active session), so logout / forced
- * revocation is just a delete. Sessions are SLIDING: `expires_at` starts at
- * `created_at + SESSION_TTL_MS`, and {@link touchSession} pushes it forward on
- * genuine activity (the admin SPA re-mints `/admin/host-admin-token` every
- * ~10 min while a tab is open). An idle session — no more mints — still
- * expires at the original 24h mark, and {@link SESSION_MAX_LIFETIME_MS} caps
- * total life so sliding can't keep a left-open tab alive forever.
+ * revocation is just a delete. Sessions are ROLLING (hub-parity P1, Q4 —
+ * adopts cloud's posture): `expires_at` starts at `created_at + SESSION_TTL_MS`
+ * (90 days), and {@link touchSession} pushes it forward on genuine activity
+ * (the admin SPA re-mints `/admin/host-admin-token` every ~10 min while a tab
+ * is open; `GET /account/session`, the app's boot/poll oracle, slides once it
+ * crosses {@link SESSION_SLIDE_THRESHOLD_MS} of its life — see
+ * `account-session.ts`). There is NO absolute ceiling: an ACTIVELY-used
+ * session rolls forward indefinitely, while an idle one (no more touches)
+ * still lapses at the 90-day mark. Was 24h sliding / 30d hard cap through
+ * 2026-07; the cap is gone. The ONLY thing that terminates a session row today
+ * is logout (which deletes it). Note what does NOT: the admin screen-lock gates
+ * token MINTS (it does not touch or expire the session row), and per-user
+ * session revocation does not exist yet (P6-era). So an actively-used session
+ * — including a stolen cookie — currently lives on until 90 idle days or an
+ * explicit logout; a per-user revoke lever is the standing gap to close.
  *
  * The cookie value is the session id directly. It's a 32-byte base64url
  * random; collision is statistically impossible. No HMAC needed because the
@@ -20,16 +29,25 @@ import type { Database } from "bun:sqlite";
 import { randomBytes } from "node:crypto";
 
 export const SESSION_COOKIE_NAME = "parachute_hub_session";
-export const SESSION_TTL_MS = 24 * 60 * 60 * 1000;
+/**
+ * Session lifetime — 90 days (hub-parity P1, Q4: adopts cloud's rolling
+ * posture). A session (and its cookie Max-Age) lasts 90 days from its last
+ * slide; {@link findSession} still expires it hard past this, and logout
+ * deletes the row outright. Was 24h (sliding, 30d hard cap) prior to this PR.
+ */
+export const SESSION_TTL_MS = 90 * 24 * 60 * 60 * 1000;
 
 /**
- * Absolute ceiling on a session's total lifetime, independent of sliding
- * renewal. Sliding ({@link touchSession}) keeps an active console signed in,
- * but a left-open-but-idle tab whose background polls keep re-minting must
- * still be force-logged-out eventually — this caps life at
- * `created_at + SESSION_MAX_LIFETIME_MS` so renewal can't extend forever.
+ * Roll a session forward once it has been used past this much of its life
+ * (30 days) — so an ACTIVE session stays alive indefinitely, while an idle one
+ * still expires at the full 90-day TTL. Callers that slide on every touch
+ * (the admin SPA's host-admin-token re-mint) don't need this threshold; it's
+ * for a POLLING caller like `GET /account/session` (the app's `/check-email`
+ * screen hits it every few seconds) that must NOT rewrite the row on every
+ * request — see `shouldSlideSession` there. Mirrors cloud's
+ * `SESSION_REFRESH_THRESHOLD_MS` (`workers/identity/src/sessions.ts`).
  */
-export const SESSION_MAX_LIFETIME_MS = 30 * 24 * 60 * 60 * 1000;
+export const SESSION_SLIDE_THRESHOLD_MS = 30 * 24 * 60 * 60 * 1000;
 
 export interface Session {
   id: string;
@@ -91,30 +109,33 @@ export function findSession(
 }
 
 /**
- * Slide a session's expiry forward to `now + SESSION_TTL_MS`, capped at
- * `created_at + SESSION_MAX_LIFETIME_MS`. No-op when the session doesn't exist.
+ * Slide a session's expiry forward to `now + SESSION_TTL_MS`. No-op when the
+ * session doesn't exist. NO ceiling (hub-parity P1, Q4) — cloud's posture,
+ * adopted here: an ACTIVELY-used session rolls forward forever; a closed tab
+ * / idle client (no more touches) still expires `SESSION_TTL_MS` after its
+ * last activity. The old absolute cap (`SESSION_MAX_LIFETIME_MS`, 30d) is
+ * removed — the bounds on a rolling session are logout, the admin
+ * screen-lock, and (P6-era) per-user delete, not a lifetime ceiling.
  *
- * This is what makes sessions sliding rather than fixed-24h: the admin SPA
- * re-mints `/admin/host-admin-token` roughly every ~10 min while a tab is open,
- * and each successful mint calls this — so an actively-used console isn't
- * hard-logged-out at the 24h mark, while a closed tab (no more mints) still
- * expires 24h after its last activity. The ceiling bounds a left-open-but-idle
- * tab (background polls keep re-minting) so sliding can't run forever.
+ * This is what makes sessions sliding rather than fixed-TTL: the admin SPA
+ * re-mints `/admin/host-admin-token` roughly every ~10 min while a tab is
+ * open, and each successful mint calls this unconditionally; `GET
+ * /account/session` (the app's boot/poll oracle) instead calls this only
+ * past `SESSION_SLIDE_THRESHOLD_MS` of remaining life (bounded slide — see
+ * `account-session.ts`), since it's polled every few seconds and an
+ * unconditional touch there would rewrite the row on every poll.
  *
  * Monotonic in practice: the production wall clock only moves forward, so the
- * slid value never undershoots a previously-written expiry; once it reaches the
- * ceiling it stays pinned there. (The write is unconditional — it does not read
- * the current expiry — so an injected backward `now` in tests would shorten the
- * session: a conservative failure mode, not a security issue.) `now` is
- * injectable for tests, matching {@link findSession}.
+ * slid value never undershoots a previously-written expiry. (The write is
+ * unconditional — it does not read the current expiry — so an injected
+ * backward `now` in tests would shorten the session: a conservative failure
+ * mode, not a security issue.) `now` is injectable for tests, matching
+ * {@link findSession}.
  */
 export function touchSession(db: Database, id: string, now: () => Date = () => new Date()): void {
   const row = db.query<Row, [string]>("SELECT * FROM sessions WHERE id = ?").get(id);
   if (!row) return;
-  const nowMs = now().getTime();
-  const slidMs = nowMs + SESSION_TTL_MS;
-  const ceilingMs = new Date(row.created_at).getTime() + SESSION_MAX_LIFETIME_MS;
-  const newExpiresAt = new Date(Math.min(slidMs, ceilingMs)).toISOString();
+  const newExpiresAt = new Date(now().getTime() + SESSION_TTL_MS).toISOString();
   db.prepare("UPDATE sessions SET expires_at = ? WHERE id = ?").run(newExpiresAt, id);
 }
 
@@ -122,6 +143,21 @@ export function deleteSession(db: Database, id: string): void {
   db.prepare("DELETE FROM sessions WHERE id = ?").run(id);
 }
 
+/**
+ * Should this live session be rolled forward? True once it has been used past
+ * {@link SESSION_SLIDE_THRESHOLD_MS} of its life — i.e. its remaining life has
+ * dropped below `SESSION_TTL_MS - SESSION_SLIDE_THRESHOLD_MS`. A
+ * freshly-created/-slid session is NOT slid; one that's crossed the threshold
+ * is. Pure — the caller (`account-session.ts`'s bounded slide, the G3 twin of
+ * cloud's `shouldSlideSession`) does the write ({@link touchSession}) + cookie
+ * re-issue only when this returns true, bounding both to ~once per threshold
+ * per session even under frequent polling.
+ */
+export function shouldSlideSession(session: Session, now: () => Date = () => new Date()): boolean {
+  const remainingMs = new Date(session.expiresAt).getTime() - now().getTime();
+  return remainingMs < SESSION_TTL_MS - SESSION_SLIDE_THRESHOLD_MS;
+}
+
 /**
  * Build a `Set-Cookie` header value for the given session id. HttpOnly +
  * SameSite=Lax + Secure (conditional) + Path=/.