mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 11:28:35 -05:00
[GH-ISSUE #15261] issue: WEBUI_AUTH_TRUSTED_EMAIL apparently stopped working for at least some api requests #17514
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#17514
Reference in New Issue
Block a user
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?
Originally created by @ccmsi on GitHub (Jun 24, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15261
Originally assigned to: @jackthgu on GitHub.
Check Existing Issues
Installation Method
Other
Open WebUI Version
0.6.15
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Greetings and thanks for offering Open Webui.
I have set up an open webui instance on a backend server with a reverse proxy in between performing SSO user verfiication and data retrieval. User information is files into request headers decalred to openwebui in envrinment variables
Environment=WEBUI_AUTH_TRUSTED_EMAIL_HEADER=REMOTE_EMAIL
Environment=WEBUI_AUTH_TRUSTED_NAME_HEADER=REMOTE_USER
The setup did work for a while. User accounts have been created by Openwebui and users had their individual sessions.
However more recently, i suppose with an update, this stopped working (fully from user persepctive) such that Openwebui starts openeing, gets stuck at listing "Chats" in side menu showing permant "Loading..." spinner and unnamed spinner in main area.
From admin perspective, reviewing network / Apache logs most requests yield HTTP 200, /api requests result in 401. Specifically /api/v1/auths , /api/v1/chats/archived , /api/v1/chats/ , /api/v1/channels/ , /api/v1/users/user/settings , /api/c1/chats/all/tags /api/models
Actual Behavior
eg from client:
curl --negotiate https://:@.../api/config
{"status":true,"name":"Open WebUI","version":"0.6.15","default_locale":"","oauth":{"providers":{}},"features":{"auth":true,"auth_trusted_header":true,"enable_ldap":false,"enable_api_key":true,"enable_signup":true,"enable_login_form":true,"enable_websocket":true}}
curl --negotiate https://:@.../api/v1/auths/
from backend:
curl http://localhost:8080/api/v1/auths/
{"detail":"Not authenticated"}
Steps to Reproduce
as above
Logs & Screenshots
from tcpdump
GET /api/config HTTP/1.1
Host: ...
sec-ch-ua-platform: "Linux"
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
sec-ch-ua: "Chromium";v="137", "Not/A)Brand";v="24"
Content-Type: application/json
sec-ch-ua-mobile: ?0
Accept: /
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: ...
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Cookie: gssapi_session=MagBearerToken=...
X-Forwarded-For: 10.1.30.12, 10.0.8.35
X-Forwarded-Host:...
X-Forwarded-Server: ...
REMOTE_USER: username
REMOTE_EMAIL: useremail@xyz
Connection: Keep-Alive
Additional Information
No response
@ccmsi commented on GitHub (Jun 24, 2025):
tcpdump excerpts are taken from backend server after passing by sso reverse proxy
POST /api/v1/auths/signin HTTP/1.1
Host: ...
sec-ch-ua-platform: "Linux"
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
sec-ch-ua: "Chromium";v="137", "Not/A)Brand";v="24"
Content-Type: application/json
sec-ch-ua-mobile: ?0
Accept: /
Origin: ...
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: ...
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Cookie: gssapi_session=...
X-Forwarded-For: ...
X-Forwarded-Host: ...
X-Forwarded-Server: ...
REMOTE_USER: user
REMOTE_EMAIL: user@xyz
Content-Length: 26
Connection: Keep-Alive
{"email":"","password":""}
HTTP/1.1 200 OK
date: Tue, 24 Jun 2025 09:13:51 GMT
server: uvicorn
content-length: 20770
content-type: application/json
set-cookie: token=...; HttpOnly; Path=/; SameSite=lax
content-encoding: zstd
vary: Accept-Encoding, Origin
x-process-time: 0
access-control-allow-origin: ...
access-control-allow-credentials: true
@ccmsi commented on GitHub (Jun 24, 2025):
from client:
curl --negotiate -X POST -H "Content-Type: application/json" -d '{"email":"","password":""}' https://:@.../api/v1/auths/signin
{"id":"d1b3d595-6c2d-48b9-a4b5-1b9d2310c57c","email":"user@xyz","name":"user","role":"admin","profile_image_url":"data:image/jpeg;base64,/9j/4AAQSkZJ...","token":"...","token_type":"Bearer","expires_at":null,"permissions":{"workspace":{"models":false,"knowledge":false,"prompts":false,"tools":false},"sharing":{"public_models":false,"public_knowledge":false,"public_prompts":false,"public_tools":false},"chat":{"controls":true,"system_prompt":true,"file_upload":true,"delete":true,"edit":true,"share":true,"export":true,"stt":true,"tts":true,"call":true,"multiple_models":true,"temporary":true,"temporary_enforced":false},"features":{"direct_tool_servers":false,"web_search":true,"image_generation":true,"code_interpreter":true,"notes":true}}}
so clearly can identify the actual user
@jrespeto commented on GitHub (Jun 26, 2025):
having the same issues accessing the model manage and connections while log in with WEBUI_AUTH_TRUSTED_EMAIL header.
@jackthgu commented on GitHub (Jun 30, 2025):
Hello, @ccmsi
I ran a quick test on our end using Caddy, but I was unable to reproduce the authentication issue.
Would it be possible for you to share your reverse proxy configuration with me?
Thanks
@ccmsi commented on GitHub (Jul 1, 2025):
Thanks for reviewing.
Our full setup will be laborious to reproduce as we use multiple layers of Apache configurations.
In the end it boils down to:
Which then becomes visible in the Requests tcpdump as above reading:
REMOTE_USER: user
REMOTE_EMAIL: user@xyz
While the source for the actual values will be apache auth modules, defining them static for testing should be sufficient.
Let me know if you need more.
@jackthgu commented on GitHub (Jul 2, 2025):
Based on the information you provided, the issue is most likely caused by using an underscore (
_) instead of a hyphen (-) in theRequestHeaderdirective. Apache can handle this internally, but the standard for HTTP headers is to use hyphens. When a request is proxied, the downstream service is expected to see the headers with hyphens.Could you try modifying your Apache configuration to use hyphens in the header names?
If the issue persists, I'll do some more testing with Apache!
@ccmsi commented on GitHub (Jul 3, 2025):
Good to know.
I updated the environment for openwebui:
Environment=WEBUI_AUTH_TRUSTED_EMAIL_HEADER=REMOTE-EMAIL
Environment=WEBUI_AUTH_TRUSTED_NAME_HEADER=REMOTE-USER
And the apache config request header name
RequestHeader set REMOTE-USER %{REMOTE_USER}e
RequestHeader set REMOTE-EMAIL %{REMOTE_EMAIL}e
The change is visible in tcpdump, however the result is still the same.
There is an additional observation though which may or may not help to identify the issue.
After the test, disabling the headers again on apache side (so they are not set) which before allowed us to work normally, this time did not in the same browser running (happwns to be Firefox, dont know if related).
Starting on a secondary browser (happens to be Chromium), it resumed the session without logging in again (token?)
Force reload on Firefox then brought up a login prompt (which i cannot pass since the auto generated users dont have passwords).
@ccmsi commented on GitHub (Jul 3, 2025):
not sure if conclusive yet, things seem to work when i selectively set headers:
@jackthgu commented on GitHub (Jul 7, 2025):
Have a question! @ccmsi
Are you currently running the front-end server separately in your server setup?
@ccmsi commented on GitHub (Jul 14, 2025):
Thanks for looking into it and sorry for delay, was on vacation.
Setup is made of 3 layers on 2 servers. Starting from users end 1st Apache instance on server1 does authentication, checks Kerberos ticket, fetches user data (ie username and email(s)), adds all of them as headers and forwards to 2nd Apache instance on server2. Server2 houses Apache for SSL and application specifics (ie, above variable to request header mappings) and forwards to openwebui on localhost.
@ccmsi commented on GitHub (Jul 14, 2025):
It seems to work IF one has successfully logged in before with a given client / browser, but does not proceed (spinning icon) if the client software has never logged in (ie Firefox has once worked - will relogin, same user & same device but different browser not used before - spinning).
If i delete "token" form a working browsers local application storage, spinning starts. If i recreate it with previous value, access succeeds.
If i copy "token" to a non working browser local application storage, spinning browser completes access / starts working.
@ccmsi commented on GitHub (Jul 15, 2025):
Below results are probably mainly a post vacation, lost my context useless results...
Correct limitation of auth data in REMOTE-USER/REMOTE-EMAIL to locations /auth and /api/v1/auths/signin works.
--- snip --- likely useless below --- except for JSON parse error on 400
POST /api/v1/auths/signin of referer /auth?redirect=%252F shows token in request but produces a 400 result.
| INFO | uvicorn.protocols.http.httptools_impl:send:476 - 10.2.2.2:2 - "POST /api/v1/auths/signin HTTP/1.1" 400 - {}
+1499612:68761cf8:94|POST /api/v1/auths/signin HTTP/1.1|Host:openwebui.site.url|sec-ch-ua-platform:"Linux"|User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36|sec-ch-ua:"Not)A;Brand";v="8", "Chromium";v="138", "Google Chrome";v="138"|Content-Type:application/json|sec-ch-ua-mobile:?0|Accept:/|Origin:https%3a/openwebui.site.url|Sec-Fetch-Site:same-origin|Sec-Fetch-Mode:cors|Sec-Fetch-Dest:empty|Referer:https%3a//openwebui.site.url/auth?redirect=%252F|Accept-Encoding:gzip, deflate, br, zstd|Accept-Language:en-US,en;q=0.9|Cookie:token=fancyneattokenhere|X-Real-IP:10.2.2.2|X-Forwarded-For:10.2.2.2, 10.2.2.2|X-Forwarded-Port:443|X-Forwarded-Proto:https|X-Forwarded-Ssl:on|REMOTE_USER:(null)|SERVER_PORT:443|REMOTE_ADDR:10.2.2.2|REMOTE_USER_FULLNAME:(null)|REMOTE_USER_GROUPS:(null)|REMOTE_USER_ALLMAILS:(null)|X-Forwarded-Host:openwebui.site.url|X-Forwarded-Server:openwebui.site.url|Content-Length:26|Connection:Keep-Alive
which results in SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data at the client
@ccmsi commented on GitHub (Aug 15, 2025):
to round up below configurations work when commenting out /api, stops working (openwebui waiting forever after intial connect, some UI) when comments are taken out
on reverse proxy:
on backend server, hosting openwebui:
@ccmsi commented on GitHub (Oct 21, 2025):
Dont know if related, should imo not make a difference, nonetheless:
Auth request header sometimes sent lowercase:
authorization: Bearer eyJhbGciO ...
The symptom is that
json reply is:
{
"detail": "User mismatch. Please sign in again."
}
401 affected URLS:
/app/v1/folders/
/app/v1/channles/
/api/v1/users/user/settings
/api/v1/chats/all/tags
/api/models
@ccmsi commented on GitHub (Oct 21, 2025):
POST https://openwebui.staging.rts.backbone.service/api/v1/auths/signin
succeeds (200) with:
id "3653...8e5c0c"
email "abc@def.xyz"
name "ccmsi"
role "admin"
profile_image_url "/user.png"
token "eyJhbG...4ssLnw"
token_type "Bearer"
expires_at null
...
GET https://openwebui.staging.rts.backbone.service/api/config
succeeds (200)
then GET https://openwebui.staging.rts.backbone.service/api/v1/folders/
fails (401)
using cookie:
token "eyJhbG...4ssLnw" (as above)
and request header:
authorization: Bearer eyJhbG...4ssLnw
response: detail "User mismatch. Please sign in again."
are there other requirements in addition to header/cookie ?
@ccmsi commented on GitHub (Oct 21, 2025):
signin of sso user autocreated of type "admin" as above (200) carries in permissions:
workspace:
models false
knowledge false
prompts false
tools false
dont have details on how they are used, but maybe related
@ccmsi commented on GitHub (Oct 21, 2025):
may be solveable by ingoring auth related headers if bearer token is set and valid