fix(e2e): run the security-service in the compose stack + route /api/v1/security

[izzywdev]

The gap

The SPA was migrated onto the provider-agnostic Security API (/api/v1/security/*), served only by backend/security. But no e2e stack ran that service. This compose builds backend/Dockerfile — the monolith, which mounts /api/auth, /api/apps, /api/organizations, /api/v1/app-registry and not /api/v1/security. So in CI the SPA's login POST 404s and the sign-in e2e times out waiting for a response that can never arrive.

The security service — which now serves all SPA auth — has had zero e2e coverage since the cutover. That is why E2E (sign-in) has been red on master since then, and red on every PR since, including #278 which touches only a shell script and markdown. A docs-and-script PR cannot break sign-in — that's the tell. It was never flake, and "pre-existing" was never a reason to wave it off.

Prod was never affected: the k8s Ingress routes /api/v1/security → fuzefront-security ahead of nginx, which is why real sign-in works.

The fix

• Adds the security service to docker-compose.e2e.yml — with Authentik + DB env, because password sign-in is brokered server-side through the flow-executor, so Authentik is required even for the plain email/password path (not just social).
• Routes /api/v1/security/ → security:3002 in deploy/e2e/nginx.e2e.conf, above the /api/ catch-all — mirroring the prod Ingress.
• frontend now depends_on it: nginx resolves upstreams at startup and refuses to boot on an unresolvable one (confirmed while testing: host not found in upstream "security").

Verified (actually run, not asserted)

docker compose -f docker-compose.e2e.yml config   → PARSE OK; services: …, security
nginx -t (upstreams host-mapped)                  → syntax is ok, test is successful

Scope

Foundation only. Not included: .github/workflows/e2e.yml (the sign-in workflow hand-starts the monolith with no Authentik — separate piece), the oidc-plumbing spec base URLs, and frontend/nginx.conf parity. hold + no auto-merge — master is deploy-on-push.

Co-Authored-By: Claude

[github-actions]

Automated code review (gate-code-review)

Credit balance is too low

Report-only — this check never blocks merge.

[github-actions]

Automated code review (gate-code-review)

Credit balance is too low

Report-only — this check never blocks merge.

[izzywdev]

Self-review catch — pushed b6a763a. The first cut of this PR would have added the container but still left sign-in broken.

I had set the security service's AUTHENTIK_REDIRECT_URI to http://localhost:4173/api/v1/security/social/callback. That URI is not in the OIDC provider's redirect_uris, and Authentik matches them matching_mode: strict — so it would have rejected the authorize call and password login would have failed anyway.

The reason it matters: password sign-in is a full authorize→code→exchange, not just a flow-executor call. services/authentikPassword.ts drives the flow-executor, then GETs the authorize URL with the session cookies and lifts code out of the 302 Location. So the redirect_uri must be registered, but never has to be browser-reachable — the server follows the redirect itself.

Fixed by reusing the shared, already-registered /api/auth/oidc/callback, which is exactly what prod's security service does (authentik.oidc.redirectUri → https://app.fuzefront.com/api/auth/oidc/callback). Registered set lives in authentik/blueprints/provider-oidc.yaml.

Re-verified: docker compose -f docker-compose.e2e.yml config → PARSE OK.

(The failing open-pr check here is the repo-wide GitHub Actions is not permitted to create or approve pull requests issue — see #278 — not a defect in this PR.)

🤖 Addressed by Claude Code

[github-actions]

Automated code review (gate-code-review)

Credit balance is too low

Report-only — this check never blocks merge.

[izzywdev]

Regression I introduced here — fixed in d164f91. Adding the security container broke the OIDC-plumbing stack:

dependency failed to start: container fuzefront-e2e-backend-1 exited (1)

I checked it against a control (the same plumbing workflow on claude/authn-google-direct, before this container existed): there the stack came up fine and the test failed on its own merits. So this crash was mine, not pre-existing.

Cause: backend/security/src/index.ts runs the same 001-009 migration chain against the same knex_migrations table as the monolith. Compose started both at once, they raced for the migration lock, and the loser exited 1 — taking the whole stack down, since frontend depends on it.

Fix: serialise — security now waits for backend to be healthy, so the chain is already applied and security's run is a harmless no-op. Chain: postgres → backend → security → frontend. Verified docker compose config parses (no cycle).

---

Worth flagging separately, because it's the next real problem rather than this PR's: that control run shows plumbing's genuine failure is

GET /?error=oidc_error&message=access_denied
backend | ❌ Failed to initialize OIDC client: connect ECONNREFUSED 172.18.0.5:9000

i.e. the OIDC flow itself returns access_denied. So this PR unblocks the stack, but plumbing will likely still fail on that — a real auth bug, tracked next, not something to hide behind "pre-existing".

🤖 Addressed by Claude Code