mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 18:45:53 +00:00
rcourtman
11a8aa3b2f
A reverse-proxy deployment that set PROXY_AUTH_ROLE_HEADER without also setting PROXY_AUTH_ADMIN_ROLE granted every proxy-authenticated user full administrator access. CheckProxyAuth only evaluated roles when both values were non-empty, so the half-configuration skipped role gating entirely and returned isAdmin=true. docs/PROXY_AUTH.md has always documented an `admin` default for that variable, but the Config struct's envconfig `default` tags are legacy and never applied (config.go), so nothing ever populated it. CheckProxyAuth is the single admin verdict all 20+ proxy-auth gates consume, so the fail-open reached every one of them. Verified on a scratch instance with PROXY_AUTH_ROLE_HEADER set and no admin role: a request carrying only `X-Proxy-Roles: user` received HTTP 200 and the full admin payload from GET /api/system/settings, HTTP 200 from POST /api/system/settings/update, and proxyAuthIsAdmin=true from /api/security/status. All three now return 403 / false, while `X-Proxy-Roles: admin` still passes. Resolve the documented default in both layers that can produce the verdict: config load populates ProxyAuthAdminRole when proxy auth is configured, and CheckProxyAuth now keys role gating on the role header alone, resolving an empty admin role through config.DefaultProxyAuthAdminRole. Configuring a role header is the operator's signal that admin access is role-gated; leaving the admin role unset must not switch that off. Deployments that intentionally treat every proxied user as an admin are unaffected: that is still expressed by leaving the role header unset.