[GH-ISSUE #782] Trusted Header examples for Docker appear to be incorrect #106

New issue

Closed

opened 2026-10-18 14:09:02 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:09:02 +00:00

Owner

Originally created by @EnigmaCurry on GitHub (Oct 28, 2025).
Original GitHub issue: https://github.com/open-webui/docs/issues/782

I am currently implementing Trusted Header authentication on my open-webui instance via traefik-forward-auth, which is very similar to the oauth2-proxy example in the docs:

## Oauth2 proxy example docker-compose.yaml in the docs (abbreviated):

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    volumes:
      - open-webui:/app/backend/data
    environment:
      - 'HOST=127.0.0.1'    ### <---- This seems wrong
      - 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-Forwarded-Email'
      - 'WEBUI_AUTH_TRUSTED_NAME_HEADER=X-Forwarded-User'
    restart: unless-stopped
  oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
    environment:
      OAUTH2_PROXY_HTTP_ADDRESS: 0.0.0.0:4180
      OAUTH2_PROXY_UPSTREAMS: http://open-webui:8080/
    ports:
      - 4180:4180/tcp

In this example, the open-webui container receives the env var HOST=127.0.0.1, which tells open-webui to bind only to the container's loopback interface. The oauth2-proxy sidecar container cannot reach the open-webui container on its loopback interface, because it is a separate container and it has its own loopback interface. The DNS name open-webui does not resolve to 127.0.0.1, it resolves to the subnet of the default Docker compose network (e.g., 172.21.0.2). So in my environment, I had to remove the HOST var so that the proxy could talk to it.

There are three other Docker examples on this page for other providers, and I believe they will have the same problem.

I think the suggestion of setting HOST=127.0.01 only makes sense if you are running open-webui and the proxy on the native host (i.e., not as containers). Since these docker-compose examples have no ports open on the open-webui container, it is effectively already protected from public access except through the proxy (or from the Docker host itself).

Originally created by @EnigmaCurry on GitHub (Oct 28, 2025). Original GitHub issue: https://github.com/open-webui/docs/issues/782 I am currently implementing [Trusted Header](https://docs.openwebui.com/features/auth/sso/#trusted-header) authentication on my open-webui instance via [traefik-forward-auth](https://github.com/thomseddon/traefik-forward-auth), which is very similar to the oauth2-proxy example in the docs: ``` ## Oauth2 proxy example docker-compose.yaml in the docs (abbreviated): services: open-webui: image: ghcr.io/open-webui/open-webui:main volumes: - open-webui:/app/backend/data environment: - 'HOST=127.0.0.1' ### <---- This seems wrong - 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-Forwarded-Email' - 'WEBUI_AUTH_TRUSTED_NAME_HEADER=X-Forwarded-User' restart: unless-stopped oauth2-proxy: image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0 environment: OAUTH2_PROXY_HTTP_ADDRESS: 0.0.0.0:4180 OAUTH2_PROXY_UPSTREAMS: http://open-webui:8080/ ports: - 4180:4180/tcp ``` In this example, the open-webui container receives the env var `HOST=127.0.0.1`, which tells open-webui to bind only to the container's loopback interface. The `oauth2-proxy` sidecar container cannot reach the open-webui container on its loopback interface, because it is a separate container and it has its own loopback interface. The DNS name `open-webui` does not resolve to 127.0.0.1, it resolves to the subnet of the default Docker compose network (e.g., `172.21.0.2`). So in my environment, I had to remove the `HOST` var so that the proxy could talk to it. There are three other Docker examples on this page for other providers, and I believe they will have the same problem. I think the suggestion of setting `HOST=127.0.01` only makes sense if you are running open-webui and the proxy on the native host (i.e., not as containers). Since these docker-compose examples have no `ports` open on the open-webui container, it is effectively already protected from public access except through the proxy (or from the Docker host itself).

bsakaguchi closed this issue

2026-10-18 14:09:02 +00:00

bsakaguchi referenced this issue

2026-10-18 14:10:32 +00:00

[PR #106] [CLOSED] Update env-configuration.md with correct case #251