[nathanklick]

Closes #53

Summary

Adds an OIDC_X_FORWARDED_HEADERS variable so operators running apache-httpd-oidc behind a trusted reverse proxy can populate OIDCXForwardedHeaders. There was previously no way to set it.

Since mod_auth_openidc 2.4.10, X-Forwarded-* headers are ignored unless explicitly listed in that directive, and the module warns once per forwarded header per request when it sees one it has not been told to trust. Not listing them is the safe default — the module is refusing to trust headers a client could spoof — so this adds an opt-in rather than changing what happens by default.

Implementation

Follows the OIDCRemoteUserClaim idiom already established in this image: ship the directive commented out, uncomment it at boot only when the variable is set.

#OIDCXForwardedHeaders ${OIDC_X_FORWARDED_HEADERS}

function configure_oidc_x_forwarded_headers {
  export OIDC_X_FORWARDED_HEADERS
  [[ -z "${OIDC_X_FORWARDED_HEADERS}" ]] && return "0"
  ...
  uncomment_config_element "${path}" "OIDCXForwardedHeaders"
}

The conditional rendering is required rather than stylistic: an empty OIDCXForwardedHeaders directive fails Apache's config parse, so the line must stay commented when the variable is unset.

Verification

Built against the published 0.3.0 image with these two files overlaid, issuing a single request carrying X-Forwarded-Host, X-Forwarded-Port and X-Forwarded-Proto:

	warnings logged	apache2ctl configtest
variable unset (default)	3	Syntax OK
variable set	0	Syntax OK

With the variable set, boot logs the expected line and the directive is active:

NOTICE --- Configuring the OIDC forwarded headers [X-Forwarded-Host X-Forwarded-Port X-Forwarded-Proto]
    OIDCXForwardedHeaders ${OIDC_X_FORWARDED_HEADERS}

With it unset, the directive stays commented and the rendered config is byte-identical to today's — existing deployments are unaffected.

shellcheck on entrypoint-helper.sh reports nothing new (the single SC1091 info about sourcing logger.sh is pre-existing).

A full docker build from source was not possible in my environment — the Debian snapshot apt-get step in the Dockerfile fails independently of this change — hence verification against the published image with the modified files overlaid.

Notes for reviewers

• Default behaviour is unchanged, and deliberately so. Anyone opting in is taking on responsibility for confirming their proxy overwrites client-supplied X-Forwarded-* rather than passing them through; otherwise this turns a spoofable header into trusted input.
• Consumers need a corresponding chart/deployment knob to pass the variable through, plus a release of this image, before it is reachable in practice.
• Unrelated observation while working here: OIDCRemoteUserClaim is only applied when OIDC_REMOTE_USER_CLAIM is non-empty, which is correct — flagging only because the commented-by-default pattern is easy to misread as the directive being inert.

🤖 Generated with Claude Code

https://claude.ai/code/session_018RE59Gf2SNENSR6AA6FuE8