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

[GH-ISSUE #20541] issue: Folders Menu Missing When Accessing via HTTPS Domain but visible when accessing 'locally' #57881

New Issue
Closed
opened 2026-05-05 21:49:20 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-05-05 21:49:20 -05:00
Owner
Copy Link

Originally created by @vasamaximov on GitHub (Jan 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20541

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.43

Ollama Version (if applicable)

No response

Operating System

Ubuntu 25.10

Browser (if applicable)

Chrome, Firefox

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

The "Folders" menu item and its content should be visible and functional regardless of access method (local IP or HTTPS domain).

Actual Behavior

When accessing via sub.myowndomain.com:

  • Folders API returns 200 OK with correct data
  • Folders UI element does not render
  • Child folder requests are NOT made (not visible in Network tab)
  • All other UI features work normally

Notes menu item is not visible as well

Steps to Reproduce

  1. Access Open-WebUI via local IP: http://192.168.1.14:3000
  2. Observe "Folders" section in left sidebar under "Chats" - visible and functional
  3. Access same instance via HTTPS domain: https://sub.myowndomain.com
  4. Enter credentials for HTTP Basic Auth
  5. Observe "Folders" section is completely missing from UI

Logs & Screenshots

Image Image

Additional Information

Summary

The "Folders" menu item disappears from the left sidebar when accessing Open-WebUI through the HTTPS domain (sub.myowndomain.com), but is visible when accessing via local IP (192.168.1.14:3000). This affects all browsers and installed applications.

Environment

Setup Configuration

  • Open-WebUI Version: [Check in Settings]
  • Deployment Method: Docker container
  • Access Methods:
    • ✅ Local IP: http://192.168.1.14:3000 (Folders visible)
    • ❌ HTTPS Domain: https://sub.myowndomain.com (Folders missing)

Infrastructure

Client Browser
  ↓
HTTPS (sub.myowndomain.com:443) on external server
  ↓
Nginx Reverse Proxy with HTTP Basic Authentication
  ↓
SSH Reverse Tunnel (port 55000 → internal:3000)
  ↓
Open-WebUI Docker Container (port 3000)

Nginx Configuration

# Public API routes (NO auth required)
location ~ ^/(api|ws|static|_app)/ {
    proxy_pass http://openwebui_backend;
    
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    
    proxy_buffering off;
    proxy_cache off;
    proxy_set_header X-Accel-Buffering no;
}

# UI routes (WITH nginx auth)
location / {
    auth_basic "Open-WebUI Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
    
    proxy_pass http://openwebui_backend;
    # [same proxy headers]
}

Affected Platforms

  • ✅ Google Chrome (v143.0.0.0)
  • ✅ Mozilla Firefox
  • ✅ Native PWA applications (installed via site prompt)

Problem Description

Steps to Reproduce

  1. Access Open-WebUI via local IP: http://192.168.1.14:3000
  2. Observe "Folders" section in left sidebar under "Chats" - visible and functional
  3. Access same instance via HTTPS domain: https://sub.myowndomain.com
  4. Enter credentials for HTTP Basic Auth
  5. Observe "Folders" section is completely missing from UI

Expected Behavior

The "Folders" menu item and its content should be visible and functional regardless of access method (local IP or HTTPS domain).

Actual Behavior

When accessing via sub.myowndomain.com:

  • Folders API returns 200 OK with correct data
  • Folders UI element does not render
  • Child folder requests are NOT made (not visible in Network tab)
  • All other UI features work normally

Screenshots

Screenshot 1: Local IP Access (Working)

URL: 192.168.1.14:3000
Status: "Not secure" (HTTP)
Left Sidebar:
├── New Chat
├── Search
├── Notes
├── Workspace
├── Folders        ← VISIBLE
│   └── [folder content visible when expanded]
├── Chats
│   └── Yesterday
│       └── Initial Greeting Exchange

Screenshot 2: HTTPS Domain Access (Broken)

URL: sub.myowndomain.com
Status: Secure (HTTPS)
Left Sidebar:
├── New Chat
├── Search
├── Workspace
├── Chats
│   └── Yesterday
│       └── Initial Greeting Exchange
[Folders section MISSING - not rendered at all]

Network Traffic Analysis - Diagnostic Data

1. Local IP Access: http://192.168.1.14:3000

Folders List Request

GET /api/v1/folders/ HTTP/1.1
Host: 192.168.1.14:3000
Referrer: http://192.168.1.14:3000/

Response: 200 OK
Body: [Correct folder data returned]

Folder Content Request (VISIBLE in Network tab)

GET /api/v1/chats/folder/33fa2e9c-0e28-4391-9c5c-dc02f1feb808/list?page=1

Response: 200 OK

Observation: Both requests are visible in DevTools Network tab. UI renders folders and makes child requests.

2. HTTPS Domain Access: https://sub.myowndomain.com

Folders List Request

GET /api/v1/folders/ HTTP/1.1
Host: sub.myowndomain.com
Referrer: https://sub.myowndomain.com/
Referrer Policy: strict-origin-when-cross-origin

Response: 200 OK
Body: [Identical folder data as local IP]

Folder Content Request (NOT VISIBLE in Network tab)

https://sub.myowndomain.com/api/v1/chats/folder/33fa2e9c-0e28-4391-9c5c-dc02f1feb808/list?page=1

[REQUEST NEVER MADE]

Critical Finding: Folders API returns 200 with correct data, but the UI component does NOT render the Folders section and does NOT make child folder requests.

Open-WebUI Server Logs

Local IP Request

2026-01-10 08:21:31.873 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.1.12:63087 - "GET /api/v1/folders/ HTTP/1.1" 200

HTTPS Domain Request

2026-01-10 08:22:04.300 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 83.221.24.18:0 - "GET /api/v1/folders/ HTTP/1.1" 200

Note: Client port shows as :0 for HTTPS requests (possible SSH tunnel/proxy artifact), but request is successful.

Root Cause Analysis

Key Observation

  • ✅ API endpoint returns 200 OK with correct data in BOTH cases
  • ❌ UI component only renders in local IP case
  • ❌ Child folder requests only made in local IP case
  • Problem is in frontend rendering logic, not API

Possible Root Causes

Cause 1: Referrer Policy / CORS / Same-Origin Issue

The frontend JavaScript may:

  • Check document.referrer or origin
  • Reject rendering if origin is external domain
  • Local IP (192.168.1.14) seen as "trusted"
  • External domain (sub.myowndomain.com) seen as "untrusted"

Evidence: Referrer Policy: strict-origin-when-cross-origin present in both requests

Cause 2: Domain Validation in Frontend

Open-WebUI frontend may contain logic like:

if (isLocalhost || isPrivateIP) {
    renderFolders();
} else if (isExternalDomain) {
    hideFolders(); // Security measure?
}

Cause 3: Cookie / Session State

  • Different cookies/session tokens for local vs. external access
  • Folders feature requires specific session flag
  • Session not properly transferred through reverse proxy auth

Cause 4: Response Header Differences

Nginx may modify headers differently for each location:

  • Local requests: Direct to docker
  • HTTPS requests: Through proxy + auth layers
  • Missing header required for frontend rendering (e.g., X-Requested-With, X-Original-URL, etc.)

Diagnostic Information

Browser Console

  • ✅ No errors reported
  • No warnings related to Folders

Response Headers Comparison Needed

Please capture response headers for both requests:

// For local IP request
GET /api/v1/folders/ → Response Headers

// For HTTPS domain request  
GET /api/v1/folders/ → Response Headers

Frontend Bundle Analysis

The UI likely contains something like:

// Show/hide Folders based on some condition
if (shouldRenderFolders) {
    renderFoldersComponent();
}

This condition differs between local and external access.

Hypothesis: Most Likely Root Cause

Location validation in Open-WebUI frontend

The application may check the request origin or URL and only render Folders for:

  • localhost
  • 127.0.0.1
  • Private IP ranges (192.168.x.x, 10.x.x.x, 172.16.x.x)

But NOT for external domains like sub.myowndomain.com, possibly as a security or licensing feature.

Evidence:

  • API works identically
  • UI rendering differs
  • Pattern matches "restricted features by access method"

Suggested Solutions

For Users (Workaround)

None currently available. The UI element is not rendered.

For Open-WebUI Developers

Investigation Points:

  1. Search codebase for domain/origin checks related to Folders
  2. Check if any features are disabled for external domains
  3. Review CORS/origin validation logic in frontend
  4. Verify response headers are identical for both access methods

Potential Fixes:

  1. Remove any hardcoded domain validation
  2. Ensure Folders feature renders regardless of access method
  3. Add configuration flag for "enable folders on external domains"
  4. Log why Folders component doesn't render (add debug mode)

Code Areas to Review:

  • Frontend components rendering left sidebar
  • Any if (isLocalhost) or domain checks
  • Cookie/session validation affecting UI features
  • Configuration that might disable features per domain

Additional Context

Working Features Through HTTPS Proxy

  • ✅ Chat functionality
  • ✅ Notes
  • ✅ Workspace
  • ✅ Search
  • ✅ Model selection
  • ✅ All API calls with 200 status

Only Broken Feature

  • ❌ Folders (not rendered)
  • ❌ Folder content requests (not made)

Reproduction Steps (Summary)

1. Start Open-WebUI in Docker on internal network
2. Set up Nginx reverse proxy with:
   - HTTPS/SSL
   - HTTP Basic Authentication
   - SSH reverse tunnel OR direct proxy
3. Create some folders in Open-WebUI (via local IP)
4. Access via local IP (192.168.1.14:3000)
   → Folders visible, fully functional
5. Access via HTTPS domain (sub.myowndomain.com)
   → Folders section missing from UI

Files / Configuration Attached

  • [Nginx configuration]
  • [Docker compose config if available]
  • [Browser DevTools Network tab export]

Expected Resolution

  1. Identify why UI renders differently for local vs. external access
  2. Remove any domain-based feature restrictions
  3. Ensure consistent UI/functionality regardless of access method
  4. Test fix with reverse proxy + HTTPS + Basic Auth setup

Bug Status: Confirmed reproducible
Severity: Medium (Feature unavailable via external access)
Impact: Users cannot use Folders functionality when accessing via external domain
Workaround: None (must use local IP access)

Originally created by @vasamaximov on GitHub (Jan 10, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20541 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.43 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 25.10 ### Browser (if applicable) Chrome, Firefox ### 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 The "Folders" menu item and its content should be visible and functional regardless of access method (local IP or HTTPS domain). ### Actual Behavior When accessing via `sub.myowndomain.com`: - Folders API returns 200 OK with correct data - **Folders UI element does not render** - Child folder requests are NOT made (not visible in Network tab) - All other UI features work normally Notes menu item is not visible as well ### Steps to Reproduce 1. Access Open-WebUI via local IP: `http://192.168.1.14:3000` 2. Observe "Folders" section in left sidebar under "Chats" - **visible and functional** 3. Access same instance via HTTPS domain: `https://sub.myowndomain.com` 4. Enter credentials for HTTP Basic Auth 5. Observe "Folders" section is **completely missing from UI** ### Logs & Screenshots <img width="294" height="221" alt="Image" src="https://github.com/user-attachments/assets/3ee6fd31-bf2f-4c98-ae4a-abe3836a73a2" /> <img width="312" height="156" alt="Image" src="https://github.com/user-attachments/assets/33320b05-ba48-43c7-84c8-9d480653a73c" /> ### Additional Information ## Summary The "Folders" menu item disappears from the left sidebar when accessing Open-WebUI through the HTTPS domain (`sub.myowndomain.com`), but is visible when accessing via local IP (`192.168.1.14:3000`). This affects all browsers and installed applications. --- ## Environment ### Setup Configuration - **Open-WebUI Version**: [Check in Settings] - **Deployment Method**: Docker container - **Access Methods**: - ✅ Local IP: `http://192.168.1.14:3000` (Folders visible) - ❌ HTTPS Domain: `https://sub.myowndomain.com` (Folders missing) ### Infrastructure ``` Client Browser ↓ HTTPS (sub.myowndomain.com:443) on external server ↓ Nginx Reverse Proxy with HTTP Basic Authentication ↓ SSH Reverse Tunnel (port 55000 → internal:3000) ↓ Open-WebUI Docker Container (port 3000) ``` ### Nginx Configuration ```nginx # Public API routes (NO auth required) location ~ ^/(api|ws|static|_app)/ { proxy_pass http://openwebui_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_buffering off; proxy_cache off; proxy_set_header X-Accel-Buffering no; } # UI routes (WITH nginx auth) location / { auth_basic "Open-WebUI Access"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://openwebui_backend; # [same proxy headers] } ``` ### Affected Platforms - ✅ Google Chrome (v143.0.0.0) - ✅ Mozilla Firefox - ✅ Native PWA applications (installed via site prompt) --- ## Problem Description ### Steps to Reproduce 1. Access Open-WebUI via local IP: `http://192.168.1.14:3000` 2. Observe "Folders" section in left sidebar under "Chats" - **visible and functional** 3. Access same instance via HTTPS domain: `https://sub.myowndomain.com` 4. Enter credentials for HTTP Basic Auth 5. Observe "Folders" section is **completely missing from UI** ### Expected Behavior The "Folders" menu item and its content should be visible and functional regardless of access method (local IP or HTTPS domain). ### Actual Behavior When accessing via `sub.myowndomain.com`: - Folders API returns 200 OK with correct data - **Folders UI element does not render** - Child folder requests are NOT made (not visible in Network tab) - All other UI features work normally --- ## Screenshots ### Screenshot 1: Local IP Access (Working) ``` URL: 192.168.1.14:3000 Status: "Not secure" (HTTP) Left Sidebar: ├── New Chat ├── Search ├── Notes ├── Workspace ├── Folders ← VISIBLE │ └── [folder content visible when expanded] ├── Chats │ └── Yesterday │ └── Initial Greeting Exchange ``` ### Screenshot 2: HTTPS Domain Access (Broken) ``` URL: sub.myowndomain.com Status: Secure (HTTPS) Left Sidebar: ├── New Chat ├── Search ├── Workspace ├── Chats │ └── Yesterday │ └── Initial Greeting Exchange [Folders section MISSING - not rendered at all] ``` --- ## Network Traffic Analysis - Diagnostic Data ### 1. Local IP Access: `http://192.168.1.14:3000` #### Folders List Request ```http GET /api/v1/folders/ HTTP/1.1 Host: 192.168.1.14:3000 Referrer: http://192.168.1.14:3000/ Response: 200 OK Body: [Correct folder data returned] ``` #### Folder Content Request (VISIBLE in Network tab) ```http GET /api/v1/chats/folder/33fa2e9c-0e28-4391-9c5c-dc02f1feb808/list?page=1 Response: 200 OK ``` **Observation**: Both requests are visible in DevTools Network tab. UI renders folders and makes child requests. --- ### 2. HTTPS Domain Access: `https://sub.myowndomain.com` #### Folders List Request ```http GET /api/v1/folders/ HTTP/1.1 Host: sub.myowndomain.com Referrer: https://sub.myowndomain.com/ Referrer Policy: strict-origin-when-cross-origin Response: 200 OK Body: [Identical folder data as local IP] ``` #### Folder Content Request (NOT VISIBLE in Network tab) ``` https://sub.myowndomain.com/api/v1/chats/folder/33fa2e9c-0e28-4391-9c5c-dc02f1feb808/list?page=1 [REQUEST NEVER MADE] ``` **Critical Finding**: Folders API returns 200 with correct data, but the UI component does NOT render the Folders section and does NOT make child folder requests. --- ## Open-WebUI Server Logs ### Local IP Request ``` 2026-01-10 08:21:31.873 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.1.12:63087 - "GET /api/v1/folders/ HTTP/1.1" 200 ``` ### HTTPS Domain Request ``` 2026-01-10 08:22:04.300 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 83.221.24.18:0 - "GET /api/v1/folders/ HTTP/1.1" 200 ``` **Note**: Client port shows as `:0` for HTTPS requests (possible SSH tunnel/proxy artifact), but request is successful. --- ## Root Cause Analysis ### Key Observation - ✅ API endpoint returns 200 OK with correct data in BOTH cases - ❌ UI component only renders in local IP case - ❌ Child folder requests only made in local IP case - **Problem is in frontend rendering logic, not API** ### Possible Root Causes #### Cause 1: Referrer Policy / CORS / Same-Origin Issue The frontend JavaScript may: - Check `document.referrer` or origin - Reject rendering if origin is external domain - Local IP (`192.168.1.14`) seen as "trusted" - External domain (`sub.myowndomain.com`) seen as "untrusted" **Evidence**: `Referrer Policy: strict-origin-when-cross-origin` present in both requests #### Cause 2: Domain Validation in Frontend Open-WebUI frontend may contain logic like: ```javascript if (isLocalhost || isPrivateIP) { renderFolders(); } else if (isExternalDomain) { hideFolders(); // Security measure? } ``` #### Cause 3: Cookie / Session State - Different cookies/session tokens for local vs. external access - Folders feature requires specific session flag - Session not properly transferred through reverse proxy auth #### Cause 4: Response Header Differences Nginx may modify headers differently for each location: - Local requests: Direct to docker - HTTPS requests: Through proxy + auth layers - Missing header required for frontend rendering (e.g., `X-Requested-With`, `X-Original-URL`, etc.) --- ## Diagnostic Information ### Browser Console - ✅ No errors reported - No warnings related to Folders ### Response Headers Comparison Needed Please capture response headers for both requests: ``` // For local IP request GET /api/v1/folders/ → Response Headers // For HTTPS domain request GET /api/v1/folders/ → Response Headers ``` ### Frontend Bundle Analysis The UI likely contains something like: ```javascript // Show/hide Folders based on some condition if (shouldRenderFolders) { renderFoldersComponent(); } ``` This condition differs between local and external access. --- ## Hypothesis: Most Likely Root Cause **Location validation in Open-WebUI frontend** The application may check the request origin or URL and only render Folders for: - `localhost` - `127.0.0.1` - Private IP ranges (192.168.x.x, 10.x.x.x, 172.16.x.x) But NOT for external domains like `sub.myowndomain.com`, possibly as a security or licensing feature. **Evidence**: - API works identically - UI rendering differs - Pattern matches "restricted features by access method" --- ## Suggested Solutions ### For Users (Workaround) None currently available. The UI element is not rendered. ### For Open-WebUI Developers **Investigation Points:** 1. Search codebase for domain/origin checks related to Folders 2. Check if any features are disabled for external domains 3. Review CORS/origin validation logic in frontend 4. Verify response headers are identical for both access methods **Potential Fixes:** 1. Remove any hardcoded domain validation 2. Ensure Folders feature renders regardless of access method 3. Add configuration flag for "enable folders on external domains" 4. Log why Folders component doesn't render (add debug mode) **Code Areas to Review:** - Frontend components rendering left sidebar - Any `if (isLocalhost)` or domain checks - Cookie/session validation affecting UI features - Configuration that might disable features per domain --- ## Additional Context ### Working Features Through HTTPS Proxy - ✅ Chat functionality - ✅ Notes - ✅ Workspace - ✅ Search - ✅ Model selection - ✅ All API calls with 200 status ### Only Broken Feature - ❌ Folders (not rendered) - ❌ Folder content requests (not made) --- ## Reproduction Steps (Summary) ``` 1. Start Open-WebUI in Docker on internal network 2. Set up Nginx reverse proxy with: - HTTPS/SSL - HTTP Basic Authentication - SSH reverse tunnel OR direct proxy 3. Create some folders in Open-WebUI (via local IP) 4. Access via local IP (192.168.1.14:3000) → Folders visible, fully functional 5. Access via HTTPS domain (sub.myowndomain.com) → Folders section missing from UI ``` --- ## Files / Configuration Attached - [Nginx configuration] - [Docker compose config if available] - [Browser DevTools Network tab export] --- ## Expected Resolution 1. Identify why UI renders differently for local vs. external access 2. Remove any domain-based feature restrictions 3. Ensure consistent UI/functionality regardless of access method 4. Test fix with reverse proxy + HTTPS + Basic Auth setup --- **Bug Status**: Confirmed reproducible **Severity**: Medium (Feature unavailable via external access) **Impact**: Users cannot use Folders functionality when accessing via external domain **Workaround**: None (must use local IP access)
GiteaMirror added the bug label 2026-05-05 21:49:20 -05:00
GiteaMirror commented 2026-05-05 21:49:22 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (Jan 10, 2026):

🔍 Similar Issues Found

I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:

  1. #19792 issue: OAuth Login redirects to https://openwebui.domain.org/oauth/oidc/openwebui.domain.org after succesful login
    by StNiosem • Dec 06, 2025 • bug

  2. #19246 issue: Access /admin/settings/images (Server connection failed)
    by plitc • Nov 17, 2025 • bug

💡 Tips:

  • If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
  • If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

<!-- gh-comment-id:3732163387 --> @owui-terminator[bot] commented on GitHub (Jan 10, 2026): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#19792](https://github.com/open-webui/open-webui/issues/19792) **issue: OAuth Login redirects to https://openwebui.domain.org/oauth/oidc/openwebui.domain.org after succesful login** *by StNiosem • Dec 06, 2025 • `bug`* 2. [#19246](https://github.com/open-webui/open-webui/issues/19246) **issue: Access /admin/settings/images (Server connection failed)** *by plitc • Nov 17, 2025 • `bug`* --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
GiteaMirror commented 2026-05-05 21:49:22 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 10, 2026):

I had an an eerily similar situation before.

I think it turned out to be CORS. Can you check your CORS configuration? What is your CORS environment variable?

<!-- gh-comment-id:3732227654 --> @Classic298 commented on GitHub (Jan 10, 2026): I had an an eerily similar situation before. I think it turned out to be CORS. Can you check your CORS configuration? What is your CORS environment variable?
GiteaMirror commented 2026-05-05 21:49:22 -05:00
Author
Owner
Copy Link

@vasamaximov commented on GitHub (Jan 10, 2026):

There are no env variables related to CORS inside the container:

root@carbon:~# docker exec -it 0ec18ec1e5a5 bash root@0ec18ec1e5a5:/app/backend# env | grep -i cors root@0ec18ec1e5a5:/app/backend#

As for the "external server" they are the following:

`
mcv@carbon:~$ curl -I -H "Origin: https://sub.myowndomain.com" https://sub.myowndomain.com/api/v1/folders/
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sat, 10 Jan 2026 10:40:52 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 7514
Connection: keep-alive
accept-ranges: bytes
last-modified: Mon, 22 Dec 2025 06:06:27 GMT
etag: "142bbab65ea38fa57440cd0e21256c35"
x-process-time: 0
access-control-allow-origin: *
access-control-allow-credentials: true
Access-Control-Allow-Origin: https://sub.myowndomain.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, PATCH
Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With

`

<!-- gh-comment-id:3732401799 --> @vasamaximov commented on GitHub (Jan 10, 2026): There are no env variables related to CORS inside the container: ` root@carbon:~# docker exec -it 0ec18ec1e5a5 bash root@0ec18ec1e5a5:/app/backend# env | grep -i cors root@0ec18ec1e5a5:/app/backend# ` As for the "external server" they are the following: ` mcv@carbon:~$ curl -I -H "Origin: https://sub.myowndomain.com" https://sub.myowndomain.com/api/v1/folders/ HTTP/1.1 200 OK Server: nginx/1.18.0 (Ubuntu) Date: Sat, 10 Jan 2026 10:40:52 GMT Content-Type: text/html; charset=utf-8 Content-Length: 7514 Connection: keep-alive accept-ranges: bytes last-modified: Mon, 22 Dec 2025 06:06:27 GMT etag: "142bbab65ea38fa57440cd0e21256c35" x-process-time: 0 access-control-allow-origin: * access-control-allow-credentials: true Access-Control-Allow-Origin: https://sub.myowndomain.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, PATCH Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With `
GiteaMirror commented 2026-05-05 21:49:23 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 10, 2026):

set this

https://docs.openwebui.com/getting-started/env-configuration#cors_allow_origin

<!-- gh-comment-id:3732411308 --> @Classic298 commented on GitHub (Jan 10, 2026): set this https://docs.openwebui.com/getting-started/env-configuration#cors_allow_origin
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#57881
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?