jhodgkin
dfdc37eec1
Cross-checks the rendered .device-badge.new count against the API's isNew count rather than forcing a synthetic new-device scenario -- that would permanently pollute the production seen_macs table on every test run. Full end-to-end verification (synthetic device injected via devices-raw.json, confirmed isNew: true, confirmed 0 false positives across the other 71 real devices) was done manually against the live deployment and cleaned up afterward; this test guards the UI/API consistency going forward. 16/16 e2e tests green across 9 spec files. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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/meall reject unauthenticated requests; a failed login grants no access even though a session cookie gets issued (that's normal@fastify/sessionbehavior, 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)
- Local logout silently failed. Frontend always sent
Content-Type: application/jsoneven 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. - OIDC login redirected to a LAN IP.
OIDC_ISSUER_URLused Authentik's internal address; its discovery document echoes back whichever host you query it through, so that LAN IP ended up as the browser-facingauthorization_endpoint. - OIDC token exchange rejected with
invalid_client. The callback handler hardcodedhttp://when reconstructing the current URL (Fastify never sees HTTPS — it terminates upstream), which sent the wrong scheme asredirect_uriin the token exchange. Authentik's own event log said plainly "Invalid redirect URI used by provider"; the error surfaced to the app as a genericinvalid_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.