58 lines
2.7 KiB
Markdown
58 lines
2.7 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.
|
|
|
|
## 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.
|