jcoffey-dev
abeee0076b
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.
90 lines
4.3 KiB
Markdown
90 lines
4.3 KiB
Markdown
# web
|
|
|
|
SvelteKit frontend. Phase 0: one page, one query box, one table. No auth,
|
|
no styling polish, no routing beyond `/`.
|
|
|
|
## What it does
|
|
|
|
Textarea for a raw SQL string → `POST {VITE_API_BASE_URL}/query` on `/api`
|
|
→ renders `{columns, rows}` as an HTML table, or shows `{error}` from a
|
|
rejected/failed query. That's the whole app — see `src/routes/+page.svelte`.
|
|
|
|
## Why a static build, not a Node server
|
|
|
|
Scaffolded with `@sveltejs/adapter-static`: this page has no server-side
|
|
data loading (all data comes from a client-side `fetch` triggered by the
|
|
submit button), so there's nothing here that needs a running SvelteKit
|
|
server. A prerendered static site is simpler to build, deploy, and reason
|
|
about than running Node in production for a page that's this thin.
|
|
|
|
Because it's static, `VITE_API_BASE_URL` is baked in at **build time**, not
|
|
read at container start. Set it before `npm run build` (or pass
|
|
`--build-arg VITE_API_BASE_URL=...` to `docker build`) — changing it later
|
|
means rebuilding, not just restarting the container.
|
|
|
|
## Building & running
|
|
|
|
```sh
|
|
npm install
|
|
cp .env.example .env # adjust VITE_API_BASE_URL if /api isn't on localhost:8080
|
|
npm run dev # local dev server with hot reload
|
|
npm run check # svelte-check, type errors
|
|
npm run build # static output to build/
|
|
npm run preview # serve the static build locally to sanity-check it
|
|
```
|
|
|
|
```sh
|
|
docker build -f Dockerfile -t sentry-web . # context is web/, not the repo root
|
|
docker run -p 3000:3000 sentry-web
|
|
```
|
|
|
|
## Tenant picker (Phase 4)
|
|
|
|
`src/routes/select-tenant` is the one route that isn't reachable by
|
|
clicking around the app -- `enterprise-auth`'s `internal/loginhandler`
|
|
redirects a browser here after an SSO login resolves to more than one
|
|
`tenant_memberships` row (see that package's doc comment), carrying a
|
|
short-lived `sentry_pending_login` cookie instead of a real session. The
|
|
page calls `GET /auth/memberships` to list the choices, and
|
|
`POST /auth/select-tenant` on a click, both via
|
|
`fetch(..., {credentials: 'include'})` (`$lib/api.ts`'s
|
|
`listMemberships`/`selectTenant`) so that cookie -- and, on success, the
|
|
real session cookie the POST response sets -- actually cross the origin
|
|
boundary between this app and `enterprise-auth`. `enterprise-auth`'s
|
|
default `POST_LOGIN_REDIRECT_URL` (this app's own base URL) is also
|
|
where `CORS_ALLOWED_ORIGIN` defaults to, and it has to be a literal
|
|
origin, not `*` -- see `api/httpserver.WithCredentialedCORS`'s doc
|
|
comment for why a credentialed `fetch` and a wildcard CORS origin can
|
|
never be combined; `getAuthFeatures` above deliberately doesn't send
|
|
credentials for exactly this reason, and is why it could stay on the
|
|
plain `WithCORS` every other endpoint in this repo uses.
|
|
|
|
Like every other route (`export const prerender = true` in this route's
|
|
own `+page.ts`), no server-side data loading -- the membership list and
|
|
the tenant choice both come from client-side `fetch` calls the same way
|
|
the root query page's does.
|
|
|
|
Verified in a real browser in this environment: a throwaway Node server
|
|
standing in for `enterprise-auth` (implementing the exact
|
|
`GET /auth/memberships`/`POST /auth/select-tenant` wire contract,
|
|
including the plain-text `http.Error` bodies the real handler sends, not
|
|
JSON) on a different origin/port than this app's dev server, driven
|
|
through the full flow -- cross-origin pending-login cookie set, the
|
|
credentialed preflight + `GET`/`POST` round trip, a real click choosing
|
|
a tenant, and the post-selection redirect landing back on `/` -- plus
|
|
the missing/expired-cookie error path separately. No Docker or live
|
|
Postgres/IdP needed for this, since the whole point was exercising this
|
|
app's own fetch/CORS/cookie wiring against a contract-accurate fake, not
|
|
`enterprise-auth`'s internals (those are `enterprise/internal/
|
|
loginhandler`'s own tests' job, already covered there).
|
|
|
|
## Why nginx, not distroless
|
|
|
|
The repo convention prefers distroless/scratch base images. Serving a
|
|
static SPA still needs *some* HTTP server, though, and `nginx:alpine` is
|
|
the boring, standard choice for that job — writing a custom static-file
|
|
binary just to stay distroless would be more engineering than a Phase 0
|
|
placeholder page justifies. `nginx.conf` here is minimal: serve `build/`,
|
|
fall back to `index.html` for client-side routing (only one route exists
|
|
today, but this is what you want the moment a second one is added).
|