fix(dashboard-api): serve the strata catalog anonymously; return the caller's role

[scttfrdmn]

Two independent API-side fixes, both traced back from portal symptoms. They're in one PR because they're both small, both in lambda/dashboard-api, and neither changes behaviour for an authenticated caller.

Fixes the API half of spore-host/spore-host#515 and spore-host/spore-host#514.

---

1. GET /api/strata/catalog no longer requires credentials (#515)

handleStrataGetCatalog takes no arguments and returns a package-level slice of five formation names. There is no per-account data in it — catalog.ts in the portal says as much. But the route sat inside the switch below getUserFromRequest:

$ curl -s -o /dev/null -w '%{http_code}' https://api.spore.host/api/strata/catalog
401
{"success":false,"error":"authentication failed"}

So browsing a static list required credentials the handler cannot use, and the portal gated the whole surface behind sign-in as a consequence.

Hoisted above the auth call, next to the three Slack OAuth exemptions that are already there for the same structural reason. Also above config.LoadDefaultConfig, since the handler needs no AWS config — one fewer thing to fail on the anonymous path.

POST /api/strata/resolve stays gated. It reaches s3://strata-registry via resolveStrataFormation with this Lambda's credentials, so it does real work and is not exempted. There's a test asserting that, so the two don't drift together later.

2. GET /teams/{id} returns the caller's role (#514)

handleGetTeam already resolved the role to gate the request, then threw it away:

if _, err := resolveTeamContext(ctx, cfg, teamID, callerARN); err != nil {

So a client had to re-derive ownership itself. The portal did, by comparing owner_arn to its account id — and that's wrong, because OwnerARN's format depends on which auth path created the team (a bare 12-digit account id for portal-federated callers, a real IAM ARN for CLI ones). GET /teams already returns role via TeamWithRole; the detail endpoint not doing so was the gap. Now it does, and clients never need to parse an ARN to infer permission.

Also documented what OwnerARN actually is — a display field, written once at creation and never read for authorization, since every owner-gated handler resolves the role from the memberships table. Not renamed: the dynamodbav tag is the stored attribute name, so changing it is a data migration. That migration, and the larger defect underneath it (the portal and CLI resolve one human to two different callerARNs, making their team memberships disjoint), is spore-host/spore-host#531.

---

Tests

The existing TestHandlerStrataGetCatalog calls handleStrataGetCatalog() directly, bypassing the router — so it passes whether the route is gated or not, and cannot see this change at all. That's part of why the gate went unnoticed: nothing exercised the path a browser actually takes.

Two router-level tests added. Verified load-bearing by reverting the routing change, which reproduces the live 401 exactly:

--- FAIL: TestHandlerStrataCatalogNeedsNoAuth (0.00s)
    main_test.go:274: status = 401, want 200 — the catalog is static and shared,
    so an unauthenticated GET must not be gated
    (body: {"success":false,"error":"authentication failed"})

go build ./..., go vet ./..., go test ./... all clean.

Deploy ordering

This is safe to deploy on its own — the portal keeps working unchanged, since it still sends X-AWS-Credentials and they still validate.

The portal-side follow-up (registry.ts → requiresAuth: false, plus tolerating a missing creds header in catalog.ts) must land only after this is live, or a signed-out visitor gets a bare 401 where they previously got a coherent sign-in prompt.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!