Summary
Allow LeafWiki to trust a username supplied by a reverse proxy via an HTTP header, gated to a configured set of trusted proxy IPs. The proxy is responsible for authentication (i.e. mTLS, OIDC at edge, OAuth2-Proxy, Tailscale serve, Authelia, etc.) and LeafWiki auto-logs in the matching existing user.
Prior art:
Motivation
Self-hosters (like myself) that centralize authentication at their reverse proxy would like to have the downstream applications trust that the user specified in some header (i.e. Remote-User or X-WEBAUTH-USER) is the user that should be signed in for that request. This simplifies deployment and provides a nice SSO experience when integrated well.
Another typical option (but not strictly required) is to provide a configuration knob for only trusting certain IPs as the trusted proxy.
Summary
Allow LeafWiki to trust a username supplied by a reverse proxy via an HTTP header, gated to a configured set of trusted proxy IPs. The proxy is responsible for authentication (i.e. mTLS, OIDC at edge, OAuth2-Proxy, Tailscale serve, Authelia, etc.) and LeafWiki auto-logs in the matching existing user.
Prior art:
Motivation
Self-hosters (like myself) that centralize authentication at their reverse proxy would like to have the downstream applications trust that the user specified in some header (i.e.
Remote-UserorX-WEBAUTH-USER) is the user that should be signed in for that request. This simplifies deployment and provides a nice SSO experience when integrated well.Another typical option (but not strictly required) is to provide a configuration knob for only trusting certain IPs as the trusted proxy.