In reverse-proxy / forward_auth setups (Caddy `forward_auth`, nginx
`auth_request`), the post-login redirect is built as an absolute URL
`{scheme}://{host}{uri}` and passed to oauth2-proxy via the `rd` query
parameter. The Caddy integration docs require `--reverse-proxy=true` but
do not mention that the host must also be added to `--whitelist-domain`.
Without `--whitelist-domain`, the absolute `rd` was rejected by the
redirect validator and, because the `sign_in`/`start` requests are served
under the proxy prefix, the remaining redirect strategies collapsed to
"/", silently losing the originally requested URL (and its query) after
login.
When `rd` is an absolute http(s) URL that fails whitelist validation but
targets the same host the request was served on, fall back to its path
component and re-validate it as a relative redirect. This is safe:
- it is a same-origin relative redirect, so it cannot redirect to a
different host;
- the extracted path is still run through the validator, so open-redirect
protections (e.g. "//", "/../") still apply;
- a `rd` pointing at a different, non-whitelisted host is left untouched,
so the other redirect strategies still run unchanged.
Regression tests model the Caddy `forward_auth` sign_in request and
verify that the originally requested path+query is preserved without a
whitelist, that a different non-whitelisted host is still rejected, and
that open-redirect payloads are still blocked.
Fixes#2940
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: 赵鑫亿 <98445030+zhaoxinyi02@users.noreply.github.com>
7361885fae