Files
homelab-monitor/e2e/README.md
T
jhodgkin 13f69ea1aa
CI / web (push) Successful in 17s
CI / api (push) Successful in 23s
docs: e2e suite writeup, update CLAUDE.md/README with OIDC verification status
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-12 22:30:21 -06:00

45 lines
2.0 KiB
Markdown

# 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
```bash
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.
## 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.