github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #15881] issue: WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email brakes in 0.6.16 #56370

New Issue
Closed
opened 2026-05-05 19:14:42 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-05-05 19:14:42 -05:00
Owner
Copy Link

Originally created by @drejom on GitHub (Jul 19, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15881

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.16,17,18

Ollama Version (if applicable)

No response

Operating System

Ubuntu 22.04

Browser (if applicable)

Chrome/Safari

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

After a recent update to OpenWebUI, I expected the application to continue functioning as it had previously when accessed via a Cloudflare Tunnel (Zero Trust). It should load the UI correctly and allow interaction with the backend and models, with no CSP violations or 500 internal errors.

Actual Behavior

When accessing the app via a custom domain proxied through a Cloudflare Tunnel, the UI fails to load and returns a 500 error. Browser console logs show multiple Content Security Policy (CSP) violations.

This behavior started after upgrading from version 0.6.15 to newer versions (including 0.6.16, 0.6.17, and 0.6.18). Reverting to 0.6.15 restores full functionality with the same setup.

Steps to Reproduce

Deploy OpenWebUI in Docker using version 0.6.16 or later.

Expose the container using cloudflared, connecting to a Cloudflare Zero Trust tunnel.

Set a custom domain to proxy through Cloudflare to the cloudflared container.

Access the OpenWebUI URL via your custom domain.

Observe:

Blank UI or error page.

500 errors in browser console.

CSP errors related to scripts, fonts, and workers.

Logs & Screenshots

Refused to load the script from Cloudflare Insights because it violates the CSP directive:
"default-src 'self' 'unsafe-inline' 'unsafe-eval'".

Refused to load a base64-encoded font because it violates the same directive.

Refused to create a worker from a blob URL because 'worker-src' was not explicitly set.

SecurityError: Failed to construct 'Worker': Access to the script at blob: is denied by the document's Content Security Policy.

OpenWebUI container logs: No relevant traceback, even with GLOBAL_LOG_LEVEL=DEBUG.

Additional Information

This setup worked perfectly with no modifications up through 0.6.15. All networking and access controls are managed through Cloudflare's Zero Trust policies, with no rate limiting or firewall rules affecting the traffic. The issue appears isolated to CSP enforcement in newer versions.

Originally created by @drejom on GitHub (Jul 19, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/15881 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.16,17,18 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04 ### Browser (if applicable) Chrome/Safari ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior After a recent update to OpenWebUI, I expected the application to continue functioning as it had previously when accessed via a Cloudflare Tunnel (Zero Trust). It should load the UI correctly and allow interaction with the backend and models, with no CSP violations or 500 internal errors. ### Actual Behavior When accessing the app via a custom domain proxied through a Cloudflare Tunnel, the UI fails to load and returns a 500 error. Browser console logs show multiple Content Security Policy (CSP) violations. This behavior started after upgrading from version 0.6.15 to newer versions (including 0.6.16, 0.6.17, and 0.6.18). Reverting to 0.6.15 restores full functionality with the same setup. ### Steps to Reproduce Deploy OpenWebUI in Docker using version 0.6.16 or later. Expose the container using cloudflared, connecting to a Cloudflare Zero Trust tunnel. Set a custom domain to proxy through Cloudflare to the cloudflared container. Access the OpenWebUI URL via your custom domain. Observe: Blank UI or error page. 500 errors in browser console. CSP errors related to scripts, fonts, and workers. ### Logs & Screenshots Refused to load the script from Cloudflare Insights because it violates the CSP directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Refused to load a base64-encoded font because it violates the same directive. Refused to create a worker from a blob URL because 'worker-src' was not explicitly set. SecurityError: Failed to construct 'Worker': Access to the script at blob:<url> is denied by the document's Content Security Policy. OpenWebUI container logs: No relevant traceback, even with GLOBAL_LOG_LEVEL=DEBUG. ### Additional Information This setup worked perfectly with no modifications up through 0.6.15. All networking and access controls are managed through Cloudflare's Zero Trust policies, with no rate limiting or firewall rules affecting the traffic. The issue appears isolated to CSP enforcement in newer versions.
GiteaMirror added the bug label 2026-05-05 19:14:43 -05:00
GiteaMirror commented 2026-05-05 19:14:46 -05:00
Author
Owner
Copy Link

@guenhter commented on GitHub (Jul 21, 2025):

Interesting. I tested WEBUI_AUTH_TRUSTED_EMAIL_HEADER last week with the latest dev and it worked like a charm. The log though is not giving much information here...

On what request are you getting the 500 in the browser?

<!-- gh-comment-id:3095283755 --> @guenhter commented on GitHub (Jul 21, 2025): Interesting. I tested `WEBUI_AUTH_TRUSTED_EMAIL_HEADER` last week with the latest dev and it worked like a charm. The log though is not giving much information here... On what request are you getting the 500 in the browser?
GiteaMirror commented 2026-05-05 19:14:47 -05:00
Author
Owner
Copy Link

@drejom commented on GitHub (Jul 21, 2025):

Strangely I'm able to authenticate and login, but immediately get the 500 error....

<!-- gh-comment-id:3097870523 --> @drejom commented on GitHub (Jul 21, 2025): Strangely I'm able to authenticate and login, but immediately get the 500 error....
GiteaMirror commented 2026-05-05 19:14:50 -05:00
Author
Owner
Copy Link

@guenhter commented on GitHub (Jul 21, 2025):

On what request are you getting the 500 in the browser?

<!-- gh-comment-id:3098323946 --> @guenhter commented on GitHub (Jul 21, 2025): On what request are you getting the 500 in the browser?
GiteaMirror commented 2026-05-05 19:14:52 -05:00
Author
Owner
Copy Link

@drejom commented on GitHub (Jul 21, 2025):

So seems it was because of an overly strict CONTENT_SECURITY_POLICY setting; removed it and all good

<!-- gh-comment-id:3099468417 --> @drejom commented on GitHub (Jul 21, 2025): So seems it was because of an overly strict CONTENT_SECURITY_POLICY setting; removed it and all good
GiteaMirror commented 2026-05-05 19:14:54 -05:00
Author
Owner
Copy Link

@drewbroadbent commented on GitHub (Jul 25, 2025):

I am currently experiencing the exact same issue, except I am not using CloudFlare. What and where is the CONTENT_SECURITY_POLICY that are you referring to?

<!-- gh-comment-id:3117000845 --> @drewbroadbent commented on GitHub (Jul 25, 2025): I am currently experiencing the exact same issue, except I am not using CloudFlare. What and where is the CONTENT_SECURITY_POLICY that are you referring to?
GiteaMirror commented 2026-05-05 19:14:56 -05:00
Author
Owner
Copy Link

@oiao commented on GitHub (Jul 30, 2025):

FYI I had the same issue and solved by setting the following env variable
CONTENT_SECURITY_POLICY="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.segment.com https://apis.google.com https://*.googleapis.com blob:; worker-src 'self' blob:; child-src 'self' blob:"

<!-- gh-comment-id:3136655752 --> @oiao commented on GitHub (Jul 30, 2025): FYI I had the same issue and solved by setting the following env variable `CONTENT_SECURITY_POLICY="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.segment.com https://apis.google.com https://*.googleapis.com blob:; worker-src 'self' blob:; child-src 'self' blob:"`
GiteaMirror commented 2026-05-05 19:14:57 -05:00
Author
Owner
Copy Link

@bKNNNNN commented on GitHub (Feb 3, 2026):

Solution for Cloudflare Access + Trusted Header Auth (v0.7.2)

"You do not have permission to access this
resource" with
WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email.

Root cause: ENABLE_SIGNUP=false blocks trusted header auth!

When a new user authenticates via trusted header, OpenWebUI calls
signup() internally to create the account. If ENABLE_SIGNUP=false,
this fails with ACCESS_PROHIBITED.

Working config:

docker run -d \                                                           
  -p 127.0.0.1:3000:8080 \                                                
  -e WEBUI_AUTH=true \                                                    
  -e WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email \ 
  -e ADMIN_EMAIL=your@email.com \                                         
  -e ENABLE_SIGNUP=true \                                                 
  -e DEFAULT_USER_ROLE=user \                                             
  ghcr.io/open-webui/open-webui:main                                      
                                                                          
Security note: ENABLE_SIGNUP=true is safe here because Cloudflare Access  
blocks unauthenticated users before they reach OpenWebUI. Binding to      
127.0.0.1 ensures only the tunnel can access the container.               
                                                                          
TL;DR: If using trusted header auth, you MUST set ENABLE_SIGNUP=true for  
auto-registration to work.
<!-- gh-comment-id:3841364788 --> @bKNNNNN commented on GitHub (Feb 3, 2026): ## Solution for Cloudflare Access + Trusted Header Auth (v0.7.2) "You do not have permission to access this resource" with `WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email`. **Root cause:** `ENABLE_SIGNUP=false` blocks trusted header auth! When a new user authenticates via trusted header, OpenWebUI calls `signup()` internally to create the account. If `ENABLE_SIGNUP=false`, this fails with `ACCESS_PROHIBITED`. **Working config:** ```bash docker run -d \ -p 127.0.0.1:3000:8080 \ -e WEBUI_AUTH=true \ -e WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email \ -e ADMIN_EMAIL=your@email.com \ -e ENABLE_SIGNUP=true \ -e DEFAULT_USER_ROLE=user \ ghcr.io/open-webui/open-webui:main Security note: ENABLE_SIGNUP=true is safe here because Cloudflare Access blocks unauthenticated users before they reach OpenWebUI. Binding to 127.0.0.1 ensures only the tunnel can access the container. TL;DR: If using trusted header auth, you MUST set ENABLE_SIGNUP=true for auto-registration to work.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#56370
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?