homelab-monitor/e2e/README.md

E2E tests

Playwright tests that drive a real browser against the live deployment (https://monitor.jerodrigged.com by default) — not a local dev server or mocked backend. They exist specifically because curl-based verification missed real bugs that only show up with an actual browser (cookies, redirects, DOM interaction).

Setup

cd e2e
npm install
npx playwright install chromium
cp .env.example .env   # fill in LOCAL_PASSWORD and OIDC_PASSWORD
npm test

OIDC_USERNAME/OIDC_PASSWORD should be the dedicated playwright-test Authentik account (blueprint-provisioned on CT121, path users/service-accounts) — never a real personal login. See docs/oidc-setup.md.

Not wired into CI

These hit the live production dashboard and a live Authentik instance, and need credentials as secrets — deliberately not run automatically on every push. Run by hand after auth-related changes.

Coverage

• local-login.spec.ts — happy path (login/logout), wrong password rejected, session survives a page reload.
• oidc-login.spec.ts — happy path through a real Authentik login, wrong password rejected (stays on Authentik, never reaches the dashboard).
• api-auth.spec.ts — /api/hosts, /api/devices, /api/auth/me all reject unauthenticated requests; a failed login grants no access even though a session cookie gets issued (that's normal @fastify/session behavior, not a leak — what matters is whether the cookie carries authentication, which it doesn't).

9 tests, confirmed stable across repeated full-suite runs with parallel workers.

Bugs these caught on first write (all fixed, kept as regression coverage)

1. Local logout silently failed. Frontend always sent Content-Type: application/json even for logout's bodyless POST; Fastify's default JSON parser rejects that combination (400). curl testing missed it — curl doesn't set that header without -d.
2. OIDC login redirected to a LAN IP. OIDC_ISSUER_URL used Authentik's internal address; its discovery document echoes back whichever host you query it through, so that LAN IP ended up as the browser-facing authorization_endpoint.
3. OIDC token exchange rejected with invalid_client. The callback handler hardcoded http:// when reconstructing the current URL (Fastify never sees HTTPS — it terminates upstream), which sent the wrong scheme as redirect_uri in the token exchange. Authentik's own event log said plainly "Invalid redirect URI used by provider"; the error surfaced to the app as a generic invalid_client.

None of these were caught by earlier curl-based verification — browser-driven auth flows (cookies, real redirect chains, a real IdP's login form) need a real browser.