github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 06:03:26 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

issue: Tool Servers permission can be bypassed with search in user Settings UI #5051

New Issue
Closed
opened 2025-11-11 16:10:48 -06:00 by GiteaMirror · 4 comments
GiteaMirror commented 2025-11-11 16:10:48 -06:00
Owner
Copy Link

Originally created by @taylorwilsdon on GitHub (May 5, 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

0.6.6

Ollama Version (if applicable)

n/a

Operating System

Docker

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.

Expected Behavior

Users without the "Direct Tool Servers" permission should not be able to add & use direct tool servers. The option to do so is hidden in the user settings UI when the permission is set as such, and attempts to set it via API should be denied.

Demo:
https://github.com/user-attachments/assets/49390477-9bab-4b2f-bb7e-e4e4be0b77ac

Actual Behavior

Users without the "Direct Tool Servers" permission should not be able to add & use direct tool servers. The option to do so is hidden in the user settings UI when the permission is set as such, but if the user searches for "Tools" the option becomes visible & functional as the the permission check does not appear to be implemented on the API route itself.

Demo:
https://github.com/user-attachments/assets/49390477-9bab-4b2f-bb7e-e4e4be0b77ac

Steps to Reproduce

Go to User Settings
Focus on the Search bar
Type "tool"
Configure a compatible Tool Server

Logs & Screenshots

https://github.com/user-attachments/assets/49390477-9bab-4b2f-bb7e-e4e4be0b77ac

Additional Information

I will open a PR to fix

Originally created by @taylorwilsdon on GitHub (May 5, 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 0.6.6 ### Ollama Version (if applicable) n/a ### Operating System Docker ### 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. ### Expected Behavior Users without the "Direct Tool Servers" permission should not be able to add & use direct tool servers. The option to do so is hidden in the user settings UI when the permission is set as such, and attempts to set it via API should be denied. Demo: https://github.com/user-attachments/assets/49390477-9bab-4b2f-bb7e-e4e4be0b77ac ### Actual Behavior Users without the "Direct Tool Servers" permission should not be able to add & use direct tool servers. The option to do so is hidden in the user settings UI when the permission is set as such, but if the user searches for "Tools" the option becomes visible & functional as the the permission check does not appear to be implemented on the API route itself. Demo: https://github.com/user-attachments/assets/49390477-9bab-4b2f-bb7e-e4e4be0b77ac ### Steps to Reproduce Go to User Settings Focus on the Search bar Type "tool" Configure a compatible Tool Server ### Logs & Screenshots https://github.com/user-attachments/assets/49390477-9bab-4b2f-bb7e-e4e4be0b77ac ### Additional Information I will open a PR to fix
GiteaMirror added the bug label 2025-11-11 16:10:48 -06:00
GiteaMirror commented 2025-11-11 16:10:49 -06:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (May 5, 2025):

@taylorwilsdon (cc @tjbck ) this same issue applies seemingly to ALL settings that an admin can hide from users

including "direct connections"

disable it in admin panel under "connections" -> allow users to have direct connections turned off

direct connections will not be shown in the user's menu anymore, but user can search for it and find it, and add custom direct connections!

Missing permission check?

Should these permissions not be migrated into the general group/role based permission system for global permission management?

@Classic298 commented on GitHub (May 5, 2025): @taylorwilsdon (cc @tjbck ) this same issue applies seemingly to ALL settings that an admin can hide from users including "direct connections" disable it in admin panel under "connections" -> allow users to have direct connections turned off direct connections will not be shown in the user's menu anymore, but user can search for it and find it, and add custom direct connections! Missing permission check? Should these permissions not be migrated into the general group/role based permission system for global permission management?
GiteaMirror commented 2025-11-11 16:10:50 -06:00
Author
Owner
Copy Link

@taylorwilsdon commented on GitHub (May 5, 2025):

@taylorwilsdon (cc @tjbck ) this same issue applies seemingly to ALL settings that an admin can hide from users

including "direct connections"

disable it in admin panel under "connections" -> allow users to have direct connections turned off

direct connections will not be shown in the user's menu anymore, but user can search for it and find it, and add custom direct connections!

Missing permission check?

Should these permissions not be migrated into the general group/role based permission system for global permission management?

Yeah that's a good callout, @tjbck do we prefer to just gate this at the API ie https://github.com/open-webui/open-webui/blob/dev/backend/open_webui/routers/users.py or implement more robust handling on the frontend too?

Want to make sure we're matching the best practices so we don't waste time here. My thought was to handle it like it is here:
https://github.com/open-webui/open-webui/blob/dev/backend/open_webui/routers/tools.py#L121 (has_permission)

@taylorwilsdon commented on GitHub (May 5, 2025): > [@taylorwilsdon](https://github.com/taylorwilsdon) (cc [@tjbck](https://github.com/tjbck) ) this same issue applies seemingly to ALL settings that an admin can hide from users > > including "direct connections" > > disable it in admin panel under "connections" -> allow users to have direct connections turned off > > direct connections will not be shown in the user's menu anymore, but user can search for it and find it, and add custom direct connections! > > Missing permission check? > > Should these permissions not be migrated into the general group/role based permission system for global permission management? Yeah that's a good callout, @tjbck do we prefer to just gate this at the API ie https://github.com/open-webui/open-webui/blob/dev/backend/open_webui/routers/users.py or implement more robust handling on the frontend too? Want to make sure we're matching the best practices so we don't waste time here. My thought was to handle it like it is here: https://github.com/open-webui/open-webui/blob/dev/backend/open_webui/routers/tools.py#L121 (`has_permission`)
GiteaMirror commented 2025-11-11 16:10:50 -06:00
Author
Owner
Copy Link

@taylorwilsdon commented on GitHub (May 5, 2025):

This does fix it but not sure if there's a preferred approach to checking for the presence of specific settings for permission checking - https://github.com/open-webui/open-webui/pull/13538 and will only apply to tool servers

@taylorwilsdon commented on GitHub (May 5, 2025): This does fix it but not sure if there's a preferred approach to checking for the presence of specific settings for permission checking - https://github.com/open-webui/open-webui/pull/13538 and will only apply to tool servers
GiteaMirror commented 2025-11-11 16:10:50 -06:00
Author
Owner
Copy Link

@tjbck commented on GitHub (May 6, 2025):

Should be addressed with ed5de96d1d, and 803b39b00c

@tjbck commented on GitHub (May 6, 2025): Should be addressed with ed5de96d1d445f4946e8219743b865cb18bb906b, and 803b39b00cbf011bdeb06f406f9d6af43c338d7e
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#5051
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?