dank/serverAppConfigs
1
0 Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(caddy,authentik): auth guarded vhosts by proxying the whole request through authentik

Browse Source 
The forward_auth target /outpost.goauthentik.io/auth/caddy does not exist
in authentik 2026.8 (verified live: 404 for every header combination; the
URL tree has no outpost auth prefix at all — the outpost worker dials back
to core over ws/outpost/<uuid>/ instead). Unauthenticated subrequests got
404, Caddy treated >=400 as 'not authenticated' and redirected browsers to
the dead path — users saw authentik's own Not-Found page.

Fix: guarded vhosts now proxy the whole request through authentik-server:9000
with X-authentik-meta-outpost/-provider/-app headers (the exact header set
this build's Traefik controller emits, adapted for Caddy). Unauthenticated
clients get the login flow served in place; once a session exists,
authentik proxies on to the provider's internal_host — now
http://caddy:8017, a new post-auth internal listener that routes straight to
the app. The chain terminates; nothing dials back into authentik.

Live DB changes applied alongside (postgres is the source of truth):
provider pk=1 authentication_flow=default-authentication-flow (was NULL —
the actual cause of the 404s) and internal_host=http://caddy:8017 (was
self-referential http://authentik-server:9000).
This commit is contained in:
Frank committed 2026-08-28 22:28:32 -07:00
1 parent 3a16375cfe
commit ef07e7d01a
5 files changed
+153 -141
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

dankclaw/Caddyfile
+90 -74
View File
@@ -11,12 +11,17 @@
# (dankclaw/pihole/addn-hosts — every name resolves to 192.168.0.143) # (dankclaw/pihole/addn-hosts — every name resolves to 192.168.0.143)
# and handed to LAN clients by the SURFboard G36 router. # and handed to LAN clients by the SURFboard G36 router.
# #
# Authentication chain (Anubis rollout, 2026-08-28): the guarded vhosts # Authentication chain (2026-08-29): the guarded vhosts (homepage, SearXNG,
# (homepage, SearXNG, Hermes, Prometheus, RomM, Copyparty) proxy EVERYTHING # Hermes, Prometheus, RomM, Copyparty) proxy EVERYTHING through the Anubis
# through the Anubis bot-challenge proxy first. Chain: client → Caddy (TLS, # bot-challenge proxy first, then the whole request is proxied THROUGH
# public listener) → Anubis :8923 (verify: DENY known AI scrapers, CHALLENGE # Authentik (2026.8 proxy-provider mode: this build serves no forward_auth
# everyone else) → Caddy's internal listener http://:8016 (Authentik # endpoint; the authentication flow runs inline — unauthenticated clients get
# forward_auth + app routing resumes; Host headers survive both hops) → app. # the login UI served in place, and once a session exists Authentik proxies
# the request on to the app via the provider's internal_host). Chain: client →
# Caddy (TLS, public listener) → Anubis :8923 (verify: DENY known AI scrapers,
# CHALLENGE everyone else) → Caddy's internal listener http://:8016 (auth
# decision; Host headers survive every hop) → authenticated traffic is
# forwarded back to http://:8017 and routed straight to the app.
# Apps with their own auth (Grafana, Gitea, OpenWebUI, ComfyUI, Jellyfin, # Apps with their own auth (Grafana, Gitea, OpenWebUI, ComfyUI, Jellyfin,
# *arr, Pi-hole) and the Authentik IdP itself (auth.franksdank.cloud — its # *arr, Pi-hole) and the Authentik IdP itself (auth.franksdank.cloud — its
# login flow must never sit behind a challenge) are exempt by construction: # login flow must never sit behind a challenge) are exempt by construction:
@@ -224,104 +229,115 @@ prowlarr.franksdank.cloud {
qbittorrent.franksdank.cloud { qbittorrent.franksdank.cloud {
reverse_proxy 192.168.0.235:8080 reverse_proxy 192.168.0.235:8080
} }
# --- Internal listener: auth decision layer -------------------------------
# --- Internal listener: where Anubis forwards accepted traffic ---
# Anubis dials http://caddy:8016 after verifying a client (TARGET in # Anubis dials http://caddy:8016 after verifying a client (TARGET in
# dankclaw/anubis/quadlet/anubis.container). Host headers survive the hop, # dankclaw/anubis/quadlet/anubis.container). Host headers survive the hop, so
# so per-vhost routing resumes here: outpost paths go straight to the # per-vhost routing resumes here: guarded vhosts proxy the WHOLE request
# Authentik outpost, everything else runs the forward_auth check and then # through Authentik (the meta headers tell Authentik which outpost, provider
# dials the app. This block is the second half of every guarded vhost. # and app are answering); unauthenticated clients get the login flow served
# in place, authenticated traffic is forwarded back to http://:8017 and
# routed straight to the app. Exempt vhosts never enter this block.
http://:8016 { http://:8016 {
@home host franksdank.cloud www.franksdank.cloud @home host franksdank.cloud www.franksdank.cloud
handle @home { handle @home {
root * /srv/homepage reverse_proxy authentik-server:9000 {
route { header_up X-authentik-meta-outpost 7e39655b-58d3-4fe6-a80a-513f31051217
# Authentik outpost (login UI + session management). header_up X-authentik-meta-provider 1
reverse_proxy /outpost.goauthentik.io/* authentik-server:9000 header_up X-authentik-meta-app name=caddy
# Forward auth: check the Authentik session before serving the page.
forward_auth authentik-server:9000 {
uri /outpost.goauthentik.io/auth/caddy
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name
trusted_proxies private_ranges
}
# Operator-only admin page. Auth is checked on the original path,
# before any rewrite, so the path matcher is reliable. 'handle'
# preserves order.
handle /admin* {
try_files /admin.html
file_server
}
# Shared data + assets: fetched by both the user page and the admin
# page. With forward_auth, any authenticated user can access them
# (the browser's Authentik session covers these fetches).
@data path /services.json /status.json /app.js /style.css /deployed.js
handle @data {
file_server
}
# Everything else (the user page).
handle {
try_files /index.html
file_server
}
} }
} }
@search host search.franksdank.cloud @search host search.franksdank.cloud
handle @search { handle @search {
reverse_proxy /outpost.goauthentik.io/* authentik-server:9000 reverse_proxy authentik-server:9000 {
forward_auth authentik-server:9000 { header_up X-authentik-meta-outpost 7e39655b-58d3-4fe6-a80a-513f31051217
uri /outpost.goauthentik.io/auth/caddy header_up X-authentik-meta-provider 1
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name header_up X-authentik-meta-app name=caddy
trusted_proxies private_ranges
} }
}
@hermes host hermes.franksdank.cloud
handle @hermes {
reverse_proxy authentik-server:9000 {
header_up X-authentik-meta-outpost 7e39655b-58d3-4fe6-a80a-513f31051217
header_up X-authentik-meta-provider 1
header_up X-authentik-meta-app name=caddy
}
}
@prometheus host prometheus.franksdank.cloud
handle @prometheus {
reverse_proxy authentik-server:9000 {
header_up X-authentik-meta-outpost 7e39655b-58d3-4fe6-a80a-513f31051217
header_up X-authentik-meta-provider 1
header_up X-authentik-meta-app name=caddy
}
}
@romm host romm.franksdank.cloud
handle @romm {
reverse_proxy authentik-server:9000 {
header_up X-authentik-meta-outpost 7e39655b-58d3-4fe6-a80a-513f31051217
header_up X-authentik-meta-provider 1
header_up X-authentik-meta-app name=caddy
}
}
@files host files.franksdank.cloud
handle @files {
reverse_proxy authentik-server:9000 {
header_up X-authentik-meta-outpost 7e39655b-58d3-4fe6-a80a-513f31051217
header_up X-authentik-meta-provider 1
header_up X-authentik-meta-app name=caddy
}
}
}
# --- Post-auth listener: where Authentik forwards authenticated traffic ----
# The proxy provider's internal_host is http://caddy:8017, so every request
# that passes authentication lands here (Host header preserved) and routes
# straight to its app. This is the end of the chain — nothing dials back
# into Authentik from here, so the chain cannot loop.
http://:8017 {
@home host franksdank.cloud www.franksdank.cloud
handle @home {
root * /srv/homepage
handle /admin* {
try_files /admin.html
file_server
}
@data path /services.json /status.json /app.js /style.css /deployed.js
handle @data {
file_server
}
handle {
try_files /index.html
file_server
}
}
@search host search.franksdank.cloud
handle @search {
reverse_proxy 192.168.0.143:8081 reverse_proxy 192.168.0.143:8081
} }
@hermes host hermes.franksdank.cloud @hermes host hermes.franksdank.cloud
handle @hermes { handle @hermes {
reverse_proxy /outpost.goauthentik.io/* authentik-server:9000
forward_auth authentik-server:9000 {
uri /outpost.goauthentik.io/auth/caddy
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name
trusted_proxies private_ranges
}
reverse_proxy hermes:8090 reverse_proxy hermes:8090
} }
@prometheus host prometheus.franksdank.cloud @prometheus host prometheus.franksdank.cloud
handle @prometheus { handle @prometheus {
reverse_proxy /outpost.goauthentik.io/* authentik-server:9000
forward_auth authentik-server:9000 {
uri /outpost.goauthentik.io/auth/caddy
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name
trusted_proxies private_ranges
}
reverse_proxy prometheus:9090 reverse_proxy prometheus:9090
} }
@romm host romm.franksdank.cloud @romm host romm.franksdank.cloud
handle @romm { handle @romm {
reverse_proxy /outpost.goauthentik.io/* authentik-server:9000
forward_auth authentik-server:9000 {
uri /outpost.goauthentik.io/auth/caddy
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name
trusted_proxies private_ranges
}
reverse_proxy 192.168.0.235:8085 reverse_proxy 192.168.0.235:8085
} }
@files host files.franksdank.cloud @files host files.franksdank.cloud
handle @files { handle @files {
reverse_proxy /outpost.goauthentik.io/* authentik-server:9000
forward_auth authentik-server:9000 {
uri /outpost.goauthentik.io/auth/caddy
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name
trusted_proxies private_ranges
}
reverse_proxy 192.168.0.235:3923 reverse_proxy 192.168.0.235:3923
} }
} }
serverAppConfigs-docs/Infrastructure/Authentik.md
+45 -50
View File
@@ -24,41 +24,27 @@ so the stack is 3 services, not 4.
```mermaid ```mermaid
graph LR graph LR
subgraph Browser U[Browser] -->|1. GET /search?q=x| A[Anubis :8923<br/>bot challenge]
U[User] A -->|2. verified, dials internal listener| C[Caddy :8016<br/>auth decision]
end C -->|3. whole request + meta headers| S[authentik-server :9000<br/>proxy provider 1]
subgraph Caddy [Caddy - auth gate] S -->|4. no session: login flow served in place| U
FA[forward_auth] S -->|5. session valid: proxies on to internal_host| P[Caddy :8017<br/>post-auth routing]
end P -->|6. app response back up the chain| U
subgraph AK [Authentik] S --> PG[(postgres)]
SRV[server :9000]
WKR[worker]
PG[(postgres)]
OUT[outpost /auth/caddy]
end
subgraph App [Target app]
A1[SearXNG / Hermes / Prometheus<br/>RomM / Copyparty / homepage]
end
U -->|1. GET /| FA
FA -->|2. GET /outpost.../auth/caddy| OUT
OUT -->|3. no session: 302 login| U
U -->|4. login at auth.franksdank.cloud| SRV
SRV --> PG
WKR --> PG
SRV -->|5. 2xx: session valid| FA
FA -->|6. proxy with headers| A1
``` ```
1. The browser hits a protected vhost (e.g. `search.franksdank.cloud`). In authentik 2026.8 the proxy provider is an OAuth2 provider and the old
2. Caddy `forward_auth` clones the request to the Authentik outpost `/outpost.goauthentik.io/auth/caddy` forward-auth endpoint no longer exists —
(`/outpost.goauthentik.io/auth/caddy`). every request that reaches it returns 404 (verified live, 2026-08-29). The
3. With no valid session, the outpost returns a `302` to the Authentik login chain therefore does not forward-auth *to* a path: guarded vhosts proxy the
page (`auth.franksdank.cloud`). **whole request through authentik** with `X-authentik-meta-outpost`,
4. The user logs in at Authentik (email + password, TOTP/WebAuthn MFA, or an `X-authentik-meta-provider` and `X-authentik-meta-app` headers. The provider's
upstream provider). `authentication_flow` (`default-authentication-flow`) decides: no session →
5. On the next request the outpost returns `2xx`; Caddy copies the the login flow is served in place; session valid → the policy passes and
`X-Authentik-*` headers and proxies to the app. authentik proxies the request on to the provider's `internal_host`
(`http://caddy:8017`, Caddy's post-auth internal listener), which routes it
straight to the app. The chain terminates — nothing dials back into
Authentik from `:8017`.
## The three compose services ## The three compose services
@@ -79,30 +65,39 @@ graph LR
## Caddy integration ## Caddy integration
The Caddyfile wraps the no-auth vhosts in a `route` block. The pattern (one Guarded vhosts proxy the **whole request through Authentik** on Caddy's
example; the others are identical): internal listener — there is no `forward_auth` anywhere: in 2026.8 the auth
endpoint the old config pointed at (`/outpost.goauthentik.io/auth/caddy`)
does not exist in the URL tree, so every unauthenticated subrequest got a
404 and browsers were served authentik's own Not-Found page (verified live,
2026-08-29). Pattern (one example; the other guarded vhosts are identical):
```caddyfile ```caddyfile
search.franksdank.cloud { http://:8016 {
route { @search host search.franksdank.cloud
# 1. The outpost path is proxied to Authentik (login UI + session). handle @search {
reverse_proxy /outpost.goauthentik.io/* authentik-server:9000 # Unauthenticated: the login flow is served in place.
# 2. forward_auth checks the session before serving the app. # Authenticated: Authentik proxies on to internal_host (:8017).
forward_auth authentik-server:9000 { reverse_proxy authentik-server:9000 {
uri /outpost.goauthentik.io/auth/caddy header_up X-authentik-meta-outpost 7e39655b-58d3-4fe6-a80a-513f31051217
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name header_up X-authentik-meta-provider 1
trusted_proxies private_ranges header_up X-authentik-meta-app name=caddy
} }
# 3. The app.
reverse_proxy 192.168.0.143:8081
} }
} }
``` ```
Vhosts protected by forward_auth: the homepage (`franksdank.cloud`, The meta headers tell authentik which outpost, provider and application are
`www.franksdank.cloud`), SearXNG, Hermes, Prometheus, RomM, Copyparty. The answering (the values come from the DB: outpost pk = the UUID embedded in
`auth.franksdank.cloud` vhost proxies to the server directly (no forward_auth — `AUTHENTIK_OUTPOST_TOKEN`, provider pk 1 = `embedded-outpost`, app slug
it *is* the login). `caddy`). The provider's `internal_host` is `http://caddy:8017`, so
authenticated traffic is handed back to Caddy's post-auth listener, which
routes it straight to the app — the chain terminates there.
Guarded vhosts: the homepage (`franksdank.cloud`, `www.franksdank.cloud`),
SearXNG, Hermes, Prometheus, RomM, Copyparty. The `auth.franksdank.cloud`
vhost proxies to the server directly — it *is* the login, and it must never
sit behind a challenge.
## Configuration (secrets) ## Configuration (secrets)
tests/authentik.bats
+9 -11
View File
@@ -95,22 +95,20 @@ UNIT_DIR="$REPO_ROOT/dankclaw/authentik/quadlet"
echo "$block" | grep -q 'reverse_proxy authentik-server:9000' echo "$block" | grep -q 'reverse_proxy authentik-server:9000'
} }
# --- Caddyfile: forward_auth on vhosts without their own auth --- # --- Caddyfile: guarded vhosts proxy the whole request through Authentik ----
@test "the Caddyfile uses forward_auth" { @test "guarded vhosts proxy the whole request through authentik on the internal listener" {
grep -q 'forward_auth' "$CADDYFILE" awk '/^http:\/\/:8016/,/^\}/' "$CADDYFILE" | grep -q 'reverse_proxy authentik-server:9000'
} }
@test "forward_auth targets the authentik outpost caddy endpoint" { @test "the auth decision carries the outpost meta headers" {
grep -q '/outpost.goauthentik.io/auth/caddy' "$CADDYFILE" grep -q 'X-authentik-meta-outpost' "$CADDYFILE"
grep -q 'X-authentik-meta-provider' "$CADDYFILE"
grep -q 'X-authentik-meta-app' "$CADDYFILE"
} }
@test "forward_auth copies the X-Authentik-Username header" { @test "authenticated traffic returns to Caddy on the post-auth listener" {
grep -q 'X-Authentik-Username' "$CADDYFILE" grep -qE '^http://:8017 \{' "$CADDYFILE"
}
@test "the outpost path is proxied to authentik in forward_auth vhosts" {
grep -q '/outpost.goauthentik.io/\*' "$CADDYFILE"
} }
# --- Homepage: moved to naked domain + www --- # --- Homepage: moved to naked domain + www ---
tests/caddyfile.bats
+4 -3
View File
@@ -125,10 +125,11 @@ CADDYFILE="$REPO_ROOT/dankclaw/Caddyfile"
# franksdank.casa is not in the same Porkbun account, so it cannot get # franksdank.casa is not in the same Porkbun account, so it cannot get
# a DNS-01 Let's Encrypt cert; it stays explicitly http. Every other # a DNS-01 Let's Encrypt cert; it stays explicitly http. Every other
# client-facing site address must carry no http:// prefix. The internal # client-facing site address must carry no http:// prefix. The internal
# listener (http://:8016) is not client-facing — Anubis dials it over # listeners (http://:8016, http://:8017) are not client-facing — Anubis
# container DNS after verifying a client, so plain HTTP is intended. # and Authentik dial them over container DNS after verifying a client,
# so plain HTTP is intended.
local offenders local offenders
offenders=$(grep -E '^http://' "$CADDYFILE" | grep -v 'plex\.franksdank\.casa' | grep -v '^http://:8016' || true) offenders=$(grep -E '^http://' "$CADDYFILE" | grep -v 'plex\.franksdank\.casa' | grep -vE '^http://:801[67]' || true)
[ -z "$offenders" ] || { echo "non-.casa http:// vhosts: $offenders"; return 1; } [ -z "$offenders" ] || { echo "non-.casa http:// vhosts: $offenders"; return 1; }
} }
tests/homepage_caddy.bats
+5 -3
View File
@@ -37,9 +37,11 @@ setup() {
local block local block
block=$(awk '/^franksdank\.cloud[[:space:]]/,/^}/' "$CADDY") block=$(awk '/^franksdank\.cloud[[:space:]]/,/^}/' "$CADDY")
echo "$block" | grep -q 'reverse_proxy anubis:8923' echo "$block" | grep -q 'reverse_proxy anubis:8923'
# The SSO check itself now runs on the internal listener that Anubis # The SSO check itself runs on the internal listener that Anubis
# forwards accepted traffic to; Host survives the hop, so per-vhost # forwards accepted traffic to; Host survives the hop, so per-vhost
# routing (and with it forward_auth) resumes there. # routing resumes there — guarded vhosts proxy the whole request
# through Authentik, which forwards authenticated traffic back on the
# post-auth listener (http://:8017) that routes straight to the app.
grep -q 'http://:8016' "$CADDY" grep -q 'http://:8016' "$CADDY"
awk '/^http:\/\/:8016/,/^\}/' "$CADDY" | grep -q 'forward_auth authentik-server:9000' awk '/^http:\/\/:8016/,/^\}/' "$CADDY" | grep -q 'reverse_proxy authentik-server:9000'
} }