Frank
0ae3650414
Bots and AI scrapers hit the SSO-fronted vhosts and eat Authentik auth work for 403s. Anubis verifies clients first: DENY for known AI scraper UAs, JS challenge for everyone else; verified traffic resumes the normal Authentik forward_auth chain on Caddy's internal listener (:8016). Chain: client -> Caddy (TLS) -> Anubis :8923 (verify) -> Caddy :8016 (auth + routing resumes; Host survives both hops) -> app. Reverse-proxy through Anubis, not forward_auth: at the pinned tag a CHALLENGE answers HTTP 200 + HTML, and forward_auth treats 200 as "authenticated" — the page would pass through unchallenged. Exempt by construction (never routed through Anubis): plex (plain HTTP legacy), auth.* (IdP login must be reachable ungated), gitea (git smart-HTTP clients cannot solve JS challenges), and every app with its own login. Pinned ghcr.io/TecharoHQ/anubis:v1.13.0 — the tag was source-verified before pinning: at this tag the policy parser is JSON-only with a minimal bots[] schema (no imports, no CEL expressions), flags are the config surface via flagenv (TARGET/POLICY_FNAME map to --target/ --policy-fname), and the image's exec-form HEALTHCHECK is inherited by the quadlet unit (dodges the v1 generator's HealthCmd space-split quirk). Rollback nuance: stopping anubis 502s everything behind the chain (the public listeners proxy through it); a true rollback is reverting the Caddyfile and redeploying, not just systemctl --user stop anubis.
46 lines
2.0 KiB
Bash
46 lines
2.0 KiB
Bash
#!/usr/bin/env bats
|
|
# Seam: the homepage site block in dankclaw/Caddyfile. Since the Anubis
|
|
# rollout the naked domain + www are guarded vhosts: the public listener
|
|
# proxies everything through Anubis (bot challenge), and the Authentik
|
|
# forward_auth for SSO runs on Caddy's internal listener (http://:8016)
|
|
# after Anubis has verified the client. caddy is not on the dev box, so the
|
|
# tests assert the structure statically.
|
|
|
|
load helpers
|
|
|
|
setup() {
|
|
CADDY="$REPO_ROOT/dankclaw/Caddyfile"
|
|
}
|
|
|
|
@test "the homepage serves /srv/homepage" {
|
|
grep -q "root \* /srv/homepage" "$CADDY"
|
|
grep -q "file_server" "$CADDY"
|
|
}
|
|
|
|
@test "the /admin/ page serves admin.html and / serves index.html" {
|
|
# Each page is served by its own 'handle' block via 'try_files'.
|
|
grep -qE "handle[[:space:]]+/admin\*" "$CADDY"
|
|
grep -qE "try_files[[:space:]]+/admin.html" "$CADDY"
|
|
grep -qE "try_files[[:space:]]+/index.html" "$CADDY"
|
|
}
|
|
|
|
@test "the shared data + assets are served to any authenticated user" {
|
|
# The data (services.json, status.json) and assets are 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).
|
|
grep -qE "@data[[:space:]]+path[[:space:]]+/services\.json[[:space:]]+/status\.json" "$CADDY"
|
|
grep -qE "handle[[:space:]]+@data" "$CADDY"
|
|
}
|
|
|
|
@test "the homepage vhost chains Anubis (public) before Authentik SSO (internal listener)" {
|
|
# Public listener: the naked domain proxies everything through Anubis.
|
|
local block
|
|
block=$(awk '/^franksdank\.cloud[[:space:]]/,/^}/' "$CADDY")
|
|
echo "$block" | grep -q 'reverse_proxy anubis:8923'
|
|
# The SSO check itself now runs on the internal listener that Anubis
|
|
# forwards accepted traffic to; Host survives the hop, so per-vhost
|
|
# routing (and with it forward_auth) resumes there.
|
|
grep -q 'http://:8016' "$CADDY"
|
|
awk '/^http:\/\/:8016/,/^\}/' "$CADDY" | grep -q 'forward_auth authentik-server:9000'
|
|
}
|