[GH-ISSUE #23406] issue: Public -> Private models are still accessible #106969

Closed
opened 2026-05-18 05:29:00 -05:00 by GiteaMirror · 2 comments
Owner

Originally created by @frenzybiscuit on GitHub (Apr 5, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23406

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

0.8.12

Ollama Version (if applicable)

N/A

Operating System

Linux

Browser (if applicable)

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

Private models should be inaccessible once set to private.

Actual Behavior

They are still accessible until the user refreshes the page.

Steps to Reproduce

Set a model to public.
Have user start to use model.
Go into the admin panel and change the model to private and set another model to public.
The user can still use the model until they refresh the page.

Logs & Screenshots

N/A

Additional Information

N/A

Originally created by @frenzybiscuit on GitHub (Apr 5, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23406 ### 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 0.8.12 ### Ollama Version (if applicable) N/A ### Operating System Linux ### Browser (if applicable) 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 Private models should be inaccessible once set to private. ### Actual Behavior They are still accessible until the user refreshes the page. ### Steps to Reproduce Set a model to public. Have user start to use model. Go into the admin panel and change the model to private and set another model to public. The user can still use the model until they refresh the page. ### Logs & Screenshots N/A ### Additional Information N/A
GiteaMirror added the bug label 2026-05-18 05:29:00 -05:00
Author
Owner

@TheCodingDragon0 commented on GitHub (Apr 5, 2026):

This is a client-side caching issue. The model list is likely loaded once when the user logs in and cached in memory. When the admin changes a model from public to private, the server-side change takes effect immediately, but the client still has the old model list until a full page refresh.

Possible fixes:

  1. Server-side enforcement (best approach): Check model visibility on every API call, not just at page load. If a user tries to use a model they no longer have access to, return a 403.

  2. WebSocket event: Broadcast a models_updated event when model visibility changes. The client listens and refreshes the model list automatically.

  3. Periodic refresh: Poll the model list endpoint every few minutes to keep it in sync.

Option 1 is the most secure since it doesn't rely on client-side behavior. The access check should be in the API middleware, not just the frontend.

<!-- gh-comment-id:4188008860 --> @TheCodingDragon0 commented on GitHub (Apr 5, 2026): This is a client-side caching issue. The model list is likely loaded once when the user logs in and cached in memory. When the admin changes a model from public to private, the server-side change takes effect immediately, but the client still has the old model list until a full page refresh. Possible fixes: 1. **Server-side enforcement** (best approach): Check model visibility on every API call, not just at page load. If a user tries to use a model they no longer have access to, return a 403. 2. **WebSocket event**: Broadcast a models_updated event when model visibility changes. The client listens and refreshes the model list automatically. 3. **Periodic refresh**: Poll the model list endpoint every few minutes to keep it in sync. Option 1 is the most secure since it doesn't rely on client-side behavior. The access check should be in the API middleware, not just the frontend.
Author
Owner

@Classic298 commented on GitHub (Apr 8, 2026):

actually moving the mouse over the model selector on the frontend should send another query to the backend to refresh the model list. Having a whole websocket event for the model list when a refresh and the other existing solution - refreshing when it's needed (i.e. when the user moves his mouse over/to the model selector) should be sufficient

<!-- gh-comment-id:4204754448 --> @Classic298 commented on GitHub (Apr 8, 2026): actually moving the mouse over the model selector on the frontend should send another query to the backend to refresh the model list. Having a whole websocket event for the model list when a refresh and the other existing solution - refreshing when it's needed (i.e. when the user moves his mouse over/to the model selector) should be sufficient
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#106969