Build and browser-verify the tenant-picker frontend page

web/src/routes/select-tenant now calls enterprise-auth's existing
GET /auth/memberships / POST /auth/select-tenant protocol (built earlier
this phase, previously called only from Go tests) via
fetch(..., {credentials: 'include'}) -- new listMemberships/selectTenant
functions in $lib/api.ts, using a dedicated request helper that reads
plain-text error bodies (loginhandler's http.Error responses), unlike
every other request helper in that file which expects JSON.

Credentialed cross-origin fetch needed CORS enterprise-auth didn't have:
api/httpserver.WithCORS's wildcard-friendly default can't be combined
with a credentialed request at all (browsers refuse to honor
Access-Control-Allow-Origin: "*" on one) -- added WithCredentialedCORS
(literal origin, Access-Control-Allow-Credentials: true) alongside it,
wired into enterprise-auth via a new CORS_ALLOWED_ORIGIN config var
defaulting to POST_LOGIN_REDIRECT_URL (web's own origin, the same
default pattern SELECT_TENANT_REDIRECT_URL already used).

adapter-static's route crawler doesn't discover a page nothing links to
(this one is only ever reached via enterprise-auth's redirect) -- fixed
with select-tenant/+page.ts's `export const prerender = true`, the same
declaration every other route already has.

Genuinely verified in a real browser in this environment, not just
type-checked: a throwaway Node server standing in for enterprise-auth's
exact wire contract (including its plain-text error bodies), driven
through the full flow via mcp__claude-in-chrome -- cross-origin
pending-login cookie set, credentialed preflight + GET/POST round trip,
a real click choosing a tenant, the post-selection redirect, and the
missing/expired-cookie error path rendering the backend's actual
message. No Docker or live Postgres/IdP needed, since the point was
exercising web's own fetch/CORS/cookie wiring, not enterprise-auth's
internals (already covered by loginhandler's own tests).

This closes the tenant-picker as the last named gap in Phase 4. What's
left is the already-disclosed live-verification caveat shared by every
Postgres/ClickHouse-backed piece and both SSO protocols: none of this
has run against a real database, external IdP, or multi-container
deployment in this environment.
This commit is contained in:
2026-08-14 23:02:09 -07:00
parent bdd42e06f6
commit abeee0076b
15 changed files with 513 additions and 85 deletions
+10 -5
View File
@@ -202,11 +202,16 @@ mutually-exclusive choice via `COMPOSE_PROFILES` (`.env` defaults to
plain `api`), sharing a host-port/network-alias trick so `alerting`/
`web` need no conditional config either way. With both storage engines'
connection/index-layer mechanisms built, deployment topology enforced at
both the Helm and docker-compose layers, and the two provisioning
mechanisms unified, and both storage engines' write paths now
per-tenant-routed too (see above), the largest remaining gap in this
phase is the tenant-picker *frontend* page — the backend protocol is
built, but `web` has no session/cookie-handling code yet to call it.
both the Helm and docker-compose layers, the two provisioning
mechanisms unified, both storage engines' write paths per-tenant-routed,
and the tenant-picker frontend page now built and browser-verified
(`web/src/routes/select-tenant`, `api/httpserver.WithCredentialedCORS`
— see `/CLAUDE.md`'s Phase 4 section and `/web/README.md`'s "Tenant
picker" section), the remaining gaps in this phase are entirely the
already-disclosed live-verification caveats: the ClickHouse/Postgres-
backed pieces have never run against a real database in this
environment, and nothing here has been tried against a real external
IdP or a real running multi-container deployment.
## Licensing boundary
+85 -18
View File
@@ -47,6 +47,14 @@ of what was already run and passed. Two genuine exceptions:
unverified is not Tantivy itself but the upstream credential/header
plumbing feeding it (ingest's `TenantResolver`, `enterprise-auth`'s
`/internal/authorize-ingest`) against a real running stack.
- The tenant-picker frontend page (§12) -- the first frontend-only piece
in this phase exercised in a real browser rather than only
type-checked: `web/src/routes/select-tenant`'s cross-origin
credentialed fetch/CORS/cookie handling, driven end-to-end via
`mcp__claude-in-chrome` against a throwaway server standing in for
`enterprise-auth`'s exact wire contract. What's unverified is the same
shape as OIDC/SAML above: this round trip against a real running
`enterprise-auth` container, not a stand-in.
Everything else — `internal/rbacstore`'s CRUD, the auth-enforcement
walkthrough, the dashboards tenant-scoping fix, the Helm chart, the
@@ -530,12 +538,12 @@ the full loop (does the operator's watch actually re-trigger a reconcile
after `-provision-tenant`'s external status write the way controller-
runtime's default predicate is expected to).
## 12. Tenant-picker backend protocol (no frontend yet, no Docker needed)
## 12. Tenant-picker, backend and frontend
Like §9, this needs nothing but a local Go toolchain -- the real
fake-IdP tests already exercise the full login → pending-login cookie →
`GET /auth/memberships``POST /auth/select-tenant` → real session
round trip:
**Backend** -- like §9, this needs nothing but a local Go toolchain --
the real fake-IdP tests already exercise the full login → pending-login
cookie → `GET /auth/memberships``POST /auth/select-tenant` → real
session round trip:
```sh
cd enterprise
@@ -555,13 +563,70 @@ go test ./internal/loginhandler/... -run 'Memberships|SelectTenant|MultipleMembe
# tenant_id outside the identity's actual memberships.
```
**Not built, and explicitly not attempted here**: the frontend page.
`web` has no session/cookie-handling code anywhere in it today (checked
while designing this), and `enterprise-auth` has no CORS middleware at
all -- a cross-origin `fetch` with credentials from `web`'s origin to
`enterprise-auth`'s would need it, and doesn't work today. Building the
actual picker UI is real, separately-scoped frontend work; this section
only closes the backend half.
**Frontend** -- `web/src/routes/select-tenant` (new), calling the
endpoints above via `fetch(..., {credentials: 'include'})`
(`$lib/api.ts`'s `listMemberships`/`selectTenant`), needed a CORS
posture `enterprise-auth` didn't have: `api/httpserver.WithCORS`'s
wildcard-friendly default can't be combined with a credentialed
request at all (browsers refuse it outright), so this needed a new
`WithCredentialedCORS` (same package, literal-origin-only) wired in via
a new `CORS_ALLOWED_ORIGIN` env var, defaulting to
`POST_LOGIN_REDIRECT_URL` (`web`'s own origin). Type-checked and built
for real:
```sh
cd web
npm run check # svelte-check -- 0 errors
npm run build # adapter-static -- confirms select-tenant.html is
# actually produced (it wasn't, at first: adapter-
# static only crawls routes reachable from a link or an
# explicit prerender entry, and nothing in the app
# links to this route since it's only ever reached via
# enterprise-auth's redirect -- fixed by adding
# select-tenant/+page.ts's `export const prerender =
# true`, the same declaration every other route here
# already has)
```
**Genuinely verified in a real browser in this environment** -- not just
type-checked, the actual cross-origin fetch/CORS/cookie behavior, driven
through `mcp__claude-in-chrome`:
1. A throwaway Node HTTP server (no dependencies) stood in for
`enterprise-auth`, implementing the exact wire contract this section's
Go tests already prove server-side: `GET /auth/memberships` and
`POST /auth/select-tenant`, the `sentry_pending_login` cookie
(`Path=/auth`), the credentialed CORS headers, and critically the
*plain-text* `http.Error` response bodies the real handler sends on
failure (not JSON -- `enterpriseAuthRequest` in `$lib/api.ts` reads
`res.text()` specifically because of this, unlike every other request
helper in that file).
2. `npm run dev` (SvelteKit dev server) pointed at that fake server via
`VITE_ENTERPRISE_AUTH_BASE_URL`, both on `localhost` but different
ports -- different origins, the same cross-origin shape a real
deployment has.
3. The browser navigated to the fake server's `/debug/start-pending-
login` (mimics `loginhandler.startTenantSelection`: sets the pending
cookie, redirects to `/select-tenant`) -- confirmed the redirect
landed on the real page, which then genuinely fetched
`GET /auth/memberships` cross-origin *with the cookie attached* and
rendered both fake tenants with their display names and roles.
4. Clicked a tenant in the real UI -- confirmed the real
`POST /auth/select-tenant` fired (with preflight), succeeded, and the
page navigated to the response's `redirect_url` via a real full page
load.
5. Reloaded `/select-tenant` directly (no pending cookie present anymore
-- the fake server clears it exactly like the real handler does) --
confirmed the page's error state renders the backend's actual
plain-text message ("missing or expired pending login...") rather
than a generic fetch-failure string.
No console errors at any point. This is the first frontend-only piece
in this entire phase that's been exercised in a real browser rather than
only type-checked or unit-tested against fakes -- everything else
frontend-adjacent (`getAuthFeatures` on the settings page, existing
Phase 0-3 routes) predates this runbook and was never re-verified here
either.
## 13. Ingest tenant identity
@@ -760,13 +825,15 @@ Full accounting: `/docs/security/threat-model.md`. Headline items:
- **Human SSO login now works for both OIDC (§3a) and SAML (§3b)** --
each verified with a real fake IdP (genuine cryptographic signing and
verification), not yet a real external IdP or a running
`enterprise-auth` container. **The tenant-picker backend protocol is
now built too** (§12) -- `GET /auth/memberships`/
`enterprise-auth` container. **The tenant-picker, backend and
frontend, is now fully built too** (§12) -- `GET /auth/memberships`/
`POST /auth/select-tenant`, backed by a short-lived pending-login
token distinct from a real session -- but nothing in `web` calls it
yet, so a multi-membership identity still can't actually finish
logging in through a browser today, just through direct HTTP calls
(which is what §12's verification does).
token distinct from a real session, and `web/src/routes/select-tenant`
actually calls it via credentialed cross-origin `fetch`, genuinely
exercised in a real browser against a contract-accurate fake backend
(§12). What's still not tried is the same caveat as OIDC/SAML above:
this whole round trip end-to-end against a real running
`enterprise-auth` container instead of a stand-in.
- No admin UI to create a `tenant_memberships` row, but §3a/§3b's manual
SQL bootstrap is gone -- `enterprise-auth -create-tenant`/
`-grant-membership-*`/`-revoke-membership-*`/`-list-memberships-tenant`
+20 -11
View File
@@ -245,20 +245,29 @@ short-lived `session.Manager` "pending login" token (a distinct Go/JWT
type from a real session, with its own disjoint claim name so a real
session token can't double as one — a real bug this design's own test
suite caught before it shipped, see `session.PendingLoginClaims`'s doc
comment) and redirects to a not-yet-served URL instead, backed by two
new endpoints (`GET /auth/memberships`, `POST /auth/select-tenant`) that
comment) and redirects to `web/src/routes/select-tenant`, backed by two
endpoints (`GET /auth/memberships`, `POST /auth/select-tenant`) that
list the identity's real tenant options and, on selection, re-derive the
role for the chosen tenant server-side (never trusting a client-supplied
role) before issuing the real session. This is the *backend protocol*
for tenant selection, verified with the same real-fake-IdP tests as the
rest of `internal/loginhandler` — the frontend page that would call it
doesn't exist (`web` has no session/cookie-handling code at all today,
and `enterprise-auth` has no CORS middleware for a cross-origin `fetch`
with credentials to work), both real, separately-scoped gaps, not
silently approximated. `GET /auth/features` (`enterprise/internal/authhandler`) reports whether
role) before issuing the real session. Both the *backend protocol* and
the *frontend page* that calls it are now built. The backend is verified
with the same real-fake-IdP tests as the rest of `internal/loginhandler`.
The frontend needed a second CORS posture — `httpserver.
WithCredentialedCORS`, a literal origin plus
`Access-Control-Allow-Credentials: true`, since a credentialed `fetch`
and a wildcard `Access-Control-Allow-Origin` can never be combined, so
this couldn't reuse `enterprise-api`'s wildcard-friendly `WithCORS` — and
is genuinely verified in a real browser in this environment (not just
type-checked): the full cross-origin pending-login-cookie round trip, a
real click choosing a tenant, the post-selection redirect, and the
missing/expired-cookie error path, all driven against a throwaway server
standing in for `enterprise-auth`'s exact wire contract. `GET
/auth/features` (`enterprise/internal/authhandler`) reports whether
OIDC/SAML are *configured*, for `/web`'s settings page to conditionally
render — independent of whether a login button actually exists yet in
the UI (it doesn't; only the HTTP endpoints do).
the UI (it doesn't yet; a user still has to be sent to
`/auth/oidc/login`/`/auth/saml/login` by some means other than clicking
something in `web`, since no page links there).
**Implemented for the one machine caller.** `/alerting`'s evaluator is
the sole service-to-service caller (`POST /query`, to evaluate rule
@@ -490,7 +499,7 @@ terms:
| Deployment actually routing traffic to `enterprise-api` (docker-compose) | **Enforced**`api`/`enterprise-api` are mutually exclusive via `COMPOSE_PROFILES`, same flag choice as Helm's `enterprise.enabled`; verified via `docker compose config`, not an actual `docker compose up` in this environment |
| Human SSO login — OIDC | **Built, verified with a real fake IdP** (not yet tried against a real external IdP) |
| Human SSO login — SAML | **Built, verified with a real fake IdP** (not yet tried against a real external IdP) |
| Multi-tenant-membership login (tenant picker) | **Backend protocol built and verified** (`GET /auth/memberships`, `POST /auth/select-tenant`, a pending-login token distinct from a real session) — no frontend page calls it yet |
| Multi-tenant-membership login (tenant picker) | **Backend and frontend built and verified** (`GET /auth/memberships`, `POST /auth/select-tenant`, a pending-login token distinct from a real session; `web/src/routes/select-tenant` calls it via credentialed cross-origin fetch, genuinely exercised in a real browser) — not yet tried against a real running `enterprise-auth` container |
| Per-resource dashboard grants (`own/granted`) | **Built, unit-tested against a fake store; live-Postgres integration tests written, not run in this environment** (only when `enterprise-api` serves traffic — plain `api` falls back to own/Admin only) |
| Query audit logging (routine queries) | **Enforced**, fail-open, and now wired to a real writer via `enterprise-api` (`audit.QueryAPILogger`) |
| Audit log tamper detection (hash chain) | **Enforced**, verified live |