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

issue: Inconsistent Tool Server Verification (Admin vs. User) #4824

New Issue
Closed
opened 2025-11-11 16:03:52 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2025-11-11 16:03:52 -06:00
Owner
Copy Link

Originally created by @tth37 on GitHub (Apr 12, 2025).

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.2

Ollama Version (if applicable)

No response

Operating System

Docker environment

Browser (if applicable)

No response

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 listed steps to reproduce the bug in detail.

Problem

There is an inconsistency in how Open-WebUI verifies Tool Server URLs between the Admin Settings panel and the User Settings panel. Additionally, user-scope tool server metadata is not cached, leading to repeated requests.

Actual Behavior

  1. Admin Settings: When adding/verifying a Tool Server in the Admin Settings panel, clicking the "Verify" button triggers a backend request to /api/v1/configs/tool_servers/verify
  2. User Settings: When adding/verifying a Tool Server in User Settings panel, clicking the "Verify" button triggers a direct POST request from the user's browser to <tool_server_url>/openapi.json
  3. Every time the Open-WebUI page is reloaded, requests are sent from the browser to fetch <tool_server_url>/openapi.json for each configured user-scope tool server. The metadata are not cached.

Critical Problems:

  • If the target Tool Server doesn't have permissive CORS headers, the browser will block the verification request.
  • If Open-WebUI is served over HTTPS, but the Tool Server is served over HTTP, browsers will also block the verification request.
  • The lack of caching for user-scope tool server metadata (openapi.json) means redundant requests are made on every page load.

Logs & Screenshots

User-scope OpenAPI Tool Server verification:
Image

Verification fails:
Image

Each time the page is reloaded:
Image

Suggestion

  1. Refactor the Tool Server verification logic in User Settings panel to proxy the request through the Open-WebUI backend, similar to how it's handled in the Admin Settings.
  2. Implement caching for the fetched openapi.json metadata for user-scope tool servers. Maybe storing this within the $settings object (currently only openapi_tool_urls are stored)
Originally created by @tth37 on GitHub (Apr 12, 2025). ### 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.2 ### Ollama Version (if applicable) _No response_ ### Operating System Docker environment ### Browser (if applicable) _No response_ ### 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 listed steps to reproduce the bug in detail. ### Problem There is an inconsistency in how Open-WebUI verifies Tool Server URLs between the Admin Settings panel and the User Settings panel. Additionally, user-scope tool server metadata is not cached, leading to repeated requests. ### Actual Behavior 1. **Admin Settings**: When adding/verifying a Tool Server in the Admin Settings panel, clicking the "Verify" button triggers a backend request to `/api/v1/configs/tool_servers/verify` 2. **User Settings**: When adding/verifying a Tool Server in **User Settings** panel, clicking the "Verify" button triggers a **direct POST request from the user's browser** to `<tool_server_url>/openapi.json` 3. Every time the Open-WebUI page is reloaded, requests are sent from the browser to fetch `<tool_server_url>/openapi.json` for **each** configured user-scope tool server. The metadata are not cached. **Critical Problems:** - If the target Tool Server doesn't have permissive CORS headers, the browser will block the verification request. - If Open-WebUI is served over HTTPS, but the Tool Server is served over HTTP, browsers will also block the verification request. - The lack of caching for user-scope tool server metadata (openapi.json) means redundant requests are made on every page load. ### Logs & Screenshots User-scope OpenAPI Tool Server verification: ![Image](https://github.com/user-attachments/assets/d7539140-d994-4a0c-9a4e-c2437e6a44cd) Verification fails: ![Image](https://github.com/user-attachments/assets/ff0e357d-2c55-4d01-9c43-203c21738a7e) Each time the page is reloaded: ![Image](https://github.com/user-attachments/assets/1c45d43d-40f4-4371-a4df-6fdfe5e33879) ### Suggestion 1. Refactor the Tool Server verification logic in User Settings panel to proxy the request through the Open-WebUI backend, similar to how it's handled in the Admin Settings. 2. Implement caching for the fetched `openapi.json` metadata for user-scope tool servers. Maybe storing this within the $settings object (currently only openapi_tool_urls are stored)
GiteaMirror added the bug label 2025-11-11 16:03:52 -06:00
GiteaMirror commented 2025-11-11 16:03:53 -06:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Apr 12, 2025):

Intended behaviour. They're "direct" tool connections. One of the advantages of hosting tool servers is allowing users to connect their LLMs to their locally hosted tools.

https://docs.openwebui.com/openapi-servers/faq

@tjbck commented on GitHub (Apr 12, 2025): Intended behaviour. They're "direct" tool connections. One of the advantages of hosting tool servers is allowing users to connect their LLMs to their locally hosted tools. https://docs.openwebui.com/openapi-servers/faq
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#4824
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?