jhodgkin/homelab-monitor

Fork 0

Files

T

jhodgkin 9b5051d3ac

CI / web (push) Successful in 17s

Details

CI / api (push) Failing after 3h0m1s

Details

Add Playwright e2e tests; fix two real bugs they caught

fix: OIDC_ISSUER_URL used Authentik's LAN IP (192.168.1.208:9443).
Authentik's discovery doc echoes back whichever host you query it
through, so that LAN IP got baked into authorization_endpoint -- the
URL the *browser* gets redirected to. Anyone off the LAN got sent to
an address they couldn't reach. Authentik was already publicly
exposed at auth.jerodrigged.com (pre-existing NPM proxy host); switched
to that, which also has a real cert so OIDC_ALLOW_INSECURE_TLS could
go back to false. Reported as "signed in via Authentik, redirected to
the local IP, failed."

fix: frontend's request() helper always sent Content-Type:
application/json, even for logout's bodyless POST. Fastify's default
JSON parser rejects an empty body under that content-type (400) --
sign-out silently failed to log the user out. curl-based testing
missed this because curl doesn't set that header without -d. Caught
immediately by the new Playwright local-login test.

e2e/: Playwright suite for local auth and OIDC login. OIDC test uses
a dedicated Authentik test user (blueprint-provisioned, never a real
personal login) so the whole flow can run unattended and repeatedly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-12 22:22:34 -06:00

3.5 KiB

Raw Blame History

Authentik OIDC setup

Local auth (bcrypt + session, the saved Vaultwarden password) is always available. When OIDC_ENABLED=true, the login page additionally shows a "Sign in with Authentik" button — this is additive, not a replacement, so the existing admin login keeps working.

How the Authentik side was provisioned

No API token or admin credentials were needed. Authentik supports blueprints — declarative YAML files it applies automatically — so the OAuth2 Provider + Application were created via /opt/authentik/blueprints-local/homelab-monitor-oidc.yaml on CT121, picked up by the worker container on startup. This is purely additive: it doesn't touch any existing user, group, or admin credential.

Blueprint volume mount added to /opt/authentik/docker-compose.yml (backed up as docker-compose.yml.bak-homelab-monitor before editing) for both server and worker.
Provider: confidential client, default-provider-authorization-implicit-consent flow (auto-approve — reasonable for a single-user personal dashboard), signed with Authentik's existing self-signed cert.
Redirect URIs (both registered): https://monitor.jerodrigged.com/api/auth/oidc/callback (primary, set in .env) and http://192.168.1.103:8090/api/auth/oidc/callback (LAN fallback, works if the tunnel/DNS is down).
Application slug: homelab-monitor.

To change anything (redirect URI, flow, scopes), edit the blueprint file on CT121 and either wait for Authentik's file-watcher or docker restart authentik-worker-1 — it re-applies on any change to the file.

Bug: LAN-IP issuer sent browsers somewhere they couldn't reach

First deploy used OIDC_ISSUER_URL=https://192.168.1.208:9443/application/o/homelab-monitor/ (Authentik's LAN IP) for discovery. Authentik's discovery document echoes back whichever host you queried it through — so authorization_endpoint came back as that same LAN IP. That value gets handed straight to the browser as a redirect target. Anyone off the LAN (or just not on wifi) got redirected to an address they couldn't reach at all — reported as "signed in via Authentik, got sent to the local IP, and it failed."

Fix: Authentik was already publicly exposed at https://auth.jerodrigged.com (NPM proxy host id 9, predates this project) with a real Let's Encrypt cert — just wasn't the one used for OIDC_ISSUER_URL. Switched to it; OIDC_ALLOW_INSECURE_TLS could then go back to false too, since it's not a self-signed cert. Always use the public issuer URL for anything a browser is ever redirected through, even though the app's own server-to-server calls (token exchange, userinfo, jwks — all made directly by the Node process, never by a browser) would have worked fine against the LAN IP too.

API-side implementation

apps/api/src/auth/oidc.ts uses openid-client v6 with PKCE + state, with an optional insecure-TLS fetch override (OIDC_ALLOW_INSECURE_TLS) for the rare case the issuer is LAN-only with a self-signed cert — not needed now that the issuer is the public URL, but kept since Authentik's LAN address still works as a fallback if auth.jerodrigged.com is ever unreachable. Routes in apps/api/src/routes/oidc.ts:

GET /api/auth/oidc/login — redirects to Authentik's authorization endpoint
GET /api/auth/oidc/callback — exchanges the code, sets req.session.username from the preferred_username (falls back to email, then sub) ID token claim

Credentials

OIDC_CLIENT_ID/OIDC_CLIENT_SECRET are in CT122's .env and saved in Vaultwarden alongside the local admin login.

3.5 KiB Raw Blame History