Open WebUI Fails to Load When Accessed Over HTTPS #3074
Comments
|
I am also facing the same issue after upgrading to v.0.3.3 |
|
Hey mate, I've had the same issue running Open WebUI under a reverse proxy with SSL. I was able to resolve it by adding the following line to the location directive in my Nginx configuration: proxy_set_header X-Forwarded-Proto $scheme;Explanation:The Mixed Content error occurs when a secure HTTPS page attempts to request an insecure HTTP resource. Modern browsers block these requests to ensure security. When Nginx acts as a reverse proxy, it terminates the SSL connection and forwards the request to the backend server (in this case, Open WebUI). The backend server needs to know the original protocol (HTTP or HTTPS) used by the client to generate URLs correctly. By adding proxy_set_header X-Forwarded-Proto $scheme;, we inform the backend server of the original request scheme. This allows the backend server to generate URLs with the correct scheme, thus avoiding mixed content errors. This small change ensures that all components in the application are aware of the original request's protocol, allowing them to behave correctly and securely. Hope this helps! |
The situation seems more serious. My open-webui is deployed on a custom port and uses HTTPS, but the console shows that the API URL accessed by the frontend doesn't even include the custom port number. |
|
Fixed on dev. |
Bug Report
Description
I have both Ollama and Open WebUI installed as containers in Docker on a server running Debian Linux 12. I have Open WebUI exposed to the Internet through Cloudflare Tunnels. I have a hostname setup on Cloudflare Tunnels Dashboard that provides a connection running over HTTPS with a valid SSL certificate and points to my Nginx Proxy Manager instance, which resolves the request to the server IP address and port where Open WebUI is running at my house.
This morning, I saw that there were image updates for both Ollama and Open WebUI. So, I updated my stack in Portainer. I navigated to my Cloudflare Open WebUI domain and logged in. I was greeted with the normal Changelog modal. When I tried to dismiss it, it wouldn't go away. So, I refreshed the page only to get a blank screen. Multiple refreshes did not help.
Bug Summary:
The Open WebUI application is failing to fully load, thus the user is presented with a blank screen.
Steps to Reproduce:
Expected Behavior:
I expect to see a Changelog modal, and after dismissing the Changelog, I should be logged into Open WebUI able to begin interacting with models through Ollama.
Actual Behavior:
Environment
Open WebUI Version: 0.3.3
Ollama (if applicable): 0.1.43
Operating System: Debian Linux 12 (server)
Browser (if applicable): Tested on Firefox 127.0 and Chrome 126.0.6478.55 on updated Arch Linux (client)
Reproduction Details
This only occurs when the user is accessing Open WebUI over HTTPS. On my local network, if I navigate to the IP address and port for Open WebUI, all is fine, except that it is running over HTTP, not HTTPS. On Firefox, when I connect to the HTTPS url, there is a lock in the address bar. If I click on that lock and then click on Connection Secure, there is a button that says "Disable Protection for Now". Clicking on that allows Open WebUI to load, though there are now lines struck through the lock symbol and the https portion of the url.
The culprit seems to be Mixed Content. This is confirmed in the Firefox console logs:
Blocked loading mixed active content “http://my-sub.customdomain.tld/api/v1/tools/” my-sub.customdomain.tldConfirmation:
Logs and Screenshots
Browser Console Logs:
TypeError: NetworkError when attempting to fetch resource. contentScript.js:43
Backend config:
Object { status: true, name: "Open WebUI", version: "0.3.3", default_locale: "en-US", default_models: null, default_prompt_suggestions: (6) […], features: {…}, audio: {…} }
layout.svelte:56:11
user-count
Object { count: 1 }
layout.svelte:89:13
usage
Object { models: [] }
layout.svelte:94:13
connected layout.svelte:83:13
Blocked loading mixed active content “http://my-sub.customdomain.tld/api/v1/tools/” my-sub.customdomain.tld
TypeError: NetworkError when attempting to fetch resource. index.ts:54:11
Array(4) [ {…}, {…}, {…}, {…} ]
index.ts:64:9
Uncaught (in promise) TypeError: s[26] is null
xr MessageInput.svelte:661
go MessageInput.svelte:451
Ot Component.js:148
_o MessageInput.svelte:78
vn Chat.svelte:1287
di Chat.svelte:1211
Ot Component.js:148
Xi Chat.svelte:119
Qr Help.svelte:40
Ot Component.js:148
as Help.svelte:40
Vt dom.js:1228
oe root.svelte:54
ae root.svelte:49
bt utils.js:165
ea layout.svelte:190
p layout.svelte:187
at scheduler.js:119
ut scheduler.js:79
MessageInput.svelte:661:17
Source map error: Error: URL constructor: is not a valid URL.
Resource URL: wasm:moz-extension://66fe8423-1afa-4144-9841-35b89c57b57d/injectedScript.bundle.js line 2 > WebAssembly.Module
Source Map URL: null
Docker Container Logs:
INFO: 65.190.149.xxx:0 - "GET / HTTP/1.1" 304 Not Modified
INFO: 65.190.149.xxx:0 - "GET /api/config HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=P0CdEGu HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /api/v1/auths/ HTTP/1.1" 200 OK
user Users Name(00000000-0000-0000-0000-000000000000) connected with session ID oeSekvM02qAsv5xWAAAw
INFO: 65.190.149.xxx:0 - "POST /ws/socket.io/?EIO=4&transport=polling&t=P0CdEL4&sid=RSpQfxKiP-1UPlpnAAAv HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=P0CdEL6&sid=RSpQfxKiP-1UPlpnAAAv HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /api/changelog HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /api/v1/users/user/settings HTTP/1.1" 200 OK
INFO: ('65.190.149.xxx', 0) - "WebSocket /ws/socket.io/?EIO=4&transport=websocket&sid=RSpQfxKiP-1UPlpnAAAv" [accepted]
INFO: connection open
INFO: 65.190.149.xxx:0 - "GET /api/v1/tools HTTP/1.1" 307 Temporary Redirect
INFO: 65.190.149.xxx:0 - "GET /api/v1/prompts/ HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /ws/socket.io/?EIO=4&transport=polling&t=P0CdEMc&sid=RSpQfxKiP-1UPlpnAAAv HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /api/v1/documents/ HTTP/1.1" 200 OK
INFO:apps.openai.main:get_all_models()
INFO:apps.ollama.main:get_all_models()
INFO: 65.190.149.xxx:0 - "GET /api/v1/configs/banners HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /api/v1/chats/tags/all HTTP/1.1" 200 OK
INFO: 65.190.149.xxx:0 - "GET /api/models HTTP/1.1" 200 OK
Screenshots (if applicable):
[Attach any relevant screenshots to help illustrate the issue]
Installation Method
I used a Docker Compose file to create a Stack in Portainer. This has been running fine for over a month. This morning I stopped the Ollama and Open WebUI containers and updated the images via the Stack in Portainer.
Additional Information
I have Ollama and Automatic1111 also running in containers with the same Docker network so that Open WebUI can easily access those services. I'm not sure if this issue is happening because the Ollama and Automatic1111 services are not HTTPS in their own right (i.e. http://host.docker.internal:11434). Though this does not seem likely, as I have been running this setup for over a month now with no issues. I just wanted to mention that those items are configured in Open WebUI just in case it could be relevant.
Note
If the bug report is incomplete or does not follow the provided instructions, it may not be addressed. Please ensure that you have followed the steps outlined in the README.md and troubleshooting.md documents, and provide all necessary information for us to reproduce and address the issue. Thank you!
The text was updated successfully, but these errors were encountered: