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

[GH-ISSUE #24096] issue: Share Links do not work since 0.9 #58851

New Issue
Closed
opened 2026-05-06 00:17:01 -05:00 by GiteaMirror · 16 comments
GiteaMirror commented 2026-05-06 00:17:01 -05:00
Owner
Copy Link

Originally created by @seamon67 on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24096

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

Ollama Version (if applicable)

No response

Operating System

Linux

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

When you click a chat share link for eg. https://<URL>/s/<share id>, it should lead to the shared Chat.

Actual Behavior

Clicking on a shared chat link takes you to the homepage of OpenWebUI.

Steps to Reproduce

  1. Create a Chat.
  2. Share the Chat.
  3. Copy the chat share link.
  4. Paste the link in your browser.
  5. This leads to the homepage of OpenWebUI.

Logs & Screenshots

Nothing wrong in the logs.

Additional Information

No response

Originally created by @seamon67 on GitHub (Apr 24, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24096 ### 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.9.2 ### Ollama Version (if applicable) _No response_ ### Operating System Linux ### 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 **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 When you click a chat share link for eg. https://\<URL\>/s/\<share id\>, it should lead to the shared Chat. ### Actual Behavior Clicking on a shared chat link takes you to the homepage of OpenWebUI. ### Steps to Reproduce 1. Create a Chat. 2. Share the Chat. 3. Copy the chat share link. 4. Paste the link in your browser. 5. This leads to the homepage of OpenWebUI. ### Logs & Screenshots Nothing wrong in the logs. ### Additional Information _No response_
GiteaMirror added the bug label 2026-05-06 00:17:01 -05:00
GiteaMirror commented 2026-05-06 00:17:04 -05:00
Author
Owner
Copy Link

@TomTheWise commented on GitHub (Apr 24, 2026):

can confirm and reproduce in current dev

<!-- gh-comment-id:4315583315 --> @TomTheWise commented on GitHub (Apr 24, 2026): can confirm and reproduce in current dev
GiteaMirror commented 2026-05-06 00:17:05 -05:00
Author
Owner
Copy Link

@sleepyddl commented on GitHub (Apr 25, 2026):

can confirm and reproduce in current dev

I also found the same issue in the dev environment

<!-- gh-comment-id:4318365856 --> @sleepyddl commented on GitHub (Apr 25, 2026): > can confirm and reproduce in current dev I also found the same issue in the dev environment
GiteaMirror commented 2026-05-06 00:17:07 -05:00
Author
Owner
Copy Link

@sleepyddl commented on GitHub (Apr 25, 2026):

If you run under http://localhost:5173, this issue will not occur, but if you run under http://ip:5173, this issue can be reproduced

<!-- gh-comment-id:4318629437 --> @sleepyddl commented on GitHub (Apr 25, 2026): If you run under http://localhost:5173, this issue will not occur, but if you run under http://ip:5173, this issue can be reproduced
GiteaMirror commented 2026-05-06 00:17:08 -05:00
Author
Owner
Copy Link

@seamon67 commented on GitHub (Apr 25, 2026):

I am using a reverse proxy

<!-- gh-comment-id:4318636920 --> @seamon67 commented on GitHub (Apr 25, 2026): I am using a reverse proxy
GiteaMirror commented 2026-05-06 00:17:09 -05:00
Author
Owner
Copy Link

@sleepyddl commented on GitHub (Apr 25, 2026):

I believe the root cause lies in an issue with the copy functionality. After debugging, I found that the share link is generated correctly, but something goes wrong when calling copyToClipboard.
This issue only occurs under HTTP (non-localhost environments). Since the system cannot access navigator.clipboard over HTTP, it falls back to simulating the copy operation by creating a DOM element. The relevant code is as follows:
textArea.style.position = 'fixed'; document.body.appendChild(textArea); textArea.focus({ preventScroll: true }); textArea.select();
Theoretically, this process should work without issues. Unfortunately, textArea.focus() does not execute as expected (I suspect the animation effect is causing the focus to be lost, but I haven’t figured out how to verify this). As a result, the text fails to be copied from the textarea.
I tested the session copy feature, which runs the exact same code and works perfectly. I noticed that the MENU does not disappear when copying the session, whereas clicking the "Copy Link" button triggers the MENU to hide. I think the MENU’s hide animation is causing the textarea to lose focus.

Is there any frontend expert who can explain this?

I’ve switched from using textarea.focus to the Selection Range method, which resolves the issue properly. I will submit a PR shortly.

<!-- gh-comment-id:4319615210 --> @sleepyddl commented on GitHub (Apr 25, 2026): I believe the root cause lies in an issue with the copy functionality. After debugging, I found that the share link is generated correctly, but something goes wrong when calling copyToClipboard. This issue only occurs under HTTP (non-[localhost](https://localhost/) environments). Since the system cannot access navigator.clipboard over HTTP, it falls back to simulating the copy operation by creating a DOM element. The relevant code is as follows: ` textArea.style.position = 'fixed'; document.body.appendChild(textArea); textArea.focus({ preventScroll: true }); textArea.select(); ` Theoretically, this process should work without issues. Unfortunately, textArea.focus() does not execute as expected (I suspect the animation effect is causing the focus to be lost, but I haven’t figured out how to verify this). As a result, the text fails to be copied from the textarea. I tested the session copy feature, which runs the exact same code and works perfectly. I noticed that the MENU does not disappear when copying the session, whereas clicking the "Copy Link" button triggers the MENU to hide. I think the MENU’s hide animation is causing the textarea to lose focus. Is there any frontend expert who can explain this? I’ve switched from using textarea.focus to the Selection Range method, which resolves the issue properly. I will submit a PR shortly.
GiteaMirror commented 2026-05-06 00:17:09 -05:00
Author
Owner
Copy Link

@seamon67 commented on GitHub (Apr 25, 2026):

I can't access old share links created before the update

<!-- gh-comment-id:4319624745 --> @seamon67 commented on GitHub (Apr 25, 2026): I can't access old share links created before the update
GiteaMirror commented 2026-05-06 00:17:10 -05:00
Author
Owner
Copy Link

@seamon67 commented on GitHub (Apr 25, 2026):

@sleepyddl Does this fix previously shared links as well - ones created before 0.9?

<!-- gh-comment-id:4319764503 --> @seamon67 commented on GitHub (Apr 25, 2026): @sleepyddl Does this fix previously shared links as well - ones created before 0.9?
GiteaMirror commented 2026-05-06 00:17:11 -05:00
Author
Owner
Copy Link

@sleepyddl commented on GitHub (Apr 25, 2026):

@sleepyddl Does this fix previously shared links as well - ones created before 0.9?

Sorry, I didn't read your problem description carefully.This fix can't resolve the link reading issue. It fixes the link creation issue instead.

<!-- gh-comment-id:4319798630 --> @sleepyddl commented on GitHub (Apr 25, 2026): > [@sleepyddl](https://github.com/sleepyddl) Does this fix previously shared links as well - ones created before 0.9? Sorry, I didn't read your problem description carefully.This fix can't resolve the link reading issue. It fixes the link creation issue instead.
GiteaMirror commented 2026-05-06 00:17:12 -05:00
Author
Owner
Copy Link

@sleepyddl commented on GitHub (Apr 25, 2026):

I just rolled back the version to 0.8.12, obtained the share link, then upgraded to 0.9.2. The issue can indeed be reproduced.

<!-- gh-comment-id:4319894674 --> @sleepyddl commented on GitHub (Apr 25, 2026): I just rolled back the version to 0.8.12, obtained the share link, then upgraded to 0.9.2. The issue can indeed be reproduced.
GiteaMirror commented 2026-05-06 00:17:14 -05:00
Author
Owner
Copy Link

@sleepyddl commented on GitHub (Apr 25, 2026):

After investigation, I've identified the root cause. I checked the historical code commits and found this is most likely a coding oversight.The method get_chat_by_share_id was mistakenly written as get_chat_by_id. I will submit a PR shortly.

<!-- gh-comment-id:4319989595 --> @sleepyddl commented on GitHub (Apr 25, 2026): After investigation, I've identified the root cause. I checked the historical code commits and found this is most likely a coding oversight.The method `get_chat_by_share_id` was mistakenly written as `get_chat_by_id`. I will submit a PR shortly.
GiteaMirror commented 2026-05-06 00:17:17 -05:00
Author
Owner
Copy Link

@jimbo-p commented on GitHub (Apr 27, 2026):

Thanks for getting a PR out, same issue here. If it helps, share links are working for our non-admin users, they seem to only be broken for when an admin opens up a /s link.

edit: old share links are working, new links are failing.

<!-- gh-comment-id:4327002758 --> @jimbo-p commented on GitHub (Apr 27, 2026): Thanks for getting a PR out, same issue here. If it helps, share links **are** working for our non-admin users, they seem to only be broken for when an admin opens up a /s link. edit: old share links are working, new links are failing.
GiteaMirror commented 2026-05-06 00:17:18 -05:00
Author
Owner
Copy Link

@Baronco commented on GitHub (Apr 29, 2026):

I’m using the latest version (0.9.2).
When a non-admin user tries to share a chat as public, it always remains private.

Only an admin user can publicly share a chat, but they cannot view the shared chat. Non-admin users, however, can view it :doomed:

The behavior is the same through the API, using the endpoints:

  • /api/v1/chats/{chat_id}/share
  • /api/v1/chats/shared/{chat_id}/access/update

If an admin user shares a chat using these endpoints, they cannot view the shared chat. Non-admin users, however, can view it.

If a non-admin user shares a chat using these endpoints, the chat remains private.

The request body sent to /api/v1/chats/shared/{chat_id}/access/update is:

{
  "access_grants": [
    {
      "principal_type": "user",   // to whom the access is granted (user or group)
      "principal_id": "*",        // specific user/group ID (use * to make it public)
      "permission": "read"        // type of permission (read or write)
    }
  ]
}

I have noticed another inconsistency: in the scenario of a non-admin user with chat ID ef4d80f7-15cd-4faa-9e5f-4d76079c6c8c, if the user shares the chat using the corresponding option in the OWUI interface (without making it public), the administrator user will not be able to view the chat using the link generated by OWUI:

http://localhost:3000/s/1450a679-c4bd-428d-8714-cd6dfaa6ff67

However, if the shared chat’s corresponding share_id GUID is removed and replaced with the chat ID ef4d80f7-15cd-4faa-9e5f-4d76079c6c8c, resulting in the following URL:

http://localhost:3000/s/ef4d80f7-15cd-4faa-9e5f-4d76079c6c8c

In this situation, the administrator user is able to view the chat.

It seems that, from the API perspective, the chat ID is being treated as if it were the share_id, while the actual share_id does not works

<!-- gh-comment-id:4347173299 --> @Baronco commented on GitHub (Apr 29, 2026): I’m using the latest version (0.9.2). When a non-admin user tries to share a chat as public, it always remains private. Only an admin user can publicly share a chat, but they cannot view the shared chat. Non-admin users, however, can view it :doomed: The behavior is the same through the API, using the endpoints: - `/api/v1/chats/{chat_id}/share` - `/api/v1/chats/shared/{chat_id}/access/update` If an admin user shares a chat using these endpoints, they cannot view the shared chat. Non-admin users, however, can view it. If a non-admin user shares a chat using these endpoints, the chat remains private. The request body sent to `/api/v1/chats/shared/{chat_id}/access/update` is: ```json { "access_grants": [ { "principal_type": "user", // to whom the access is granted (user or group) "principal_id": "*", // specific user/group ID (use * to make it public) "permission": "read" // type of permission (read or write) } ] } ``` --- I have noticed another inconsistency: in the scenario of a non-admin user with chat ID `ef4d80f7-15cd-4faa-9e5f-4d76079c6c8c`, if the user shares the chat using the corresponding option in the OWUI interface (without making it public), the administrator user will not be able to view the chat using the link generated by OWUI: ``` http://localhost:3000/s/1450a679-c4bd-428d-8714-cd6dfaa6ff67 ``` However, if the shared chat’s corresponding `share_id` GUID is removed and replaced with the chat ID `ef4d80f7-15cd-4faa-9e5f-4d76079c6c8c`, resulting in the following URL: ``` http://localhost:3000/s/ef4d80f7-15cd-4faa-9e5f-4d76079c6c8c ``` In this situation, the administrator user is able to view the chat. It seems that, from the API perspective, the **chat ID** is being treated as if it were the **share_id**, while the actual **share_id** does not works
GiteaMirror commented 2026-05-06 00:17:19 -05:00
Author
Owner
Copy Link

@sleepyddl commented on GitHub (May 1, 2026):

Thanks for getting a PR out, same issue here. If it helps, share links are working for our non-admin users, they seem to only be broken for when an admin opens up a /s link.

edit: old share links are working, new links are failing.

@jimbo-p Sorry, I didn't understand what you meant. Is this phenomenon 'old share links are working, new links are failing.' caused by the PR I submitted?

<!-- gh-comment-id:4359271114 --> @sleepyddl commented on GitHub (May 1, 2026): > Thanks for getting a PR out, same issue here. If it helps, share links **are** working for our non-admin users, they seem to only be broken for when an admin opens up a /s link. > > edit: old share links are working, new links are failing. @jimbo-p Sorry, I didn't understand what you meant. Is this phenomenon 'old share links are working, new links are failing.' caused by the PR I submitted?
GiteaMirror commented 2026-05-06 00:17:21 -05:00
Author
Owner
Copy Link

@jimbo-p commented on GitHub (May 1, 2026):

Thanks for getting a PR out, same issue here. If it helps, share links are working for our non-admin users, they seem to only be broken for when an admin opens up a /s link.
edit: old share links are working, new links are failing.

@jimbo-p Sorry, I didn't understand what you meant. Is this phenomenon 'old share links are working, new links are failing.' caused by the PR I submitted?

No, I had just noticed that a share link generated pre-0.9 still opened up. Anything generated after 0.9 was failing. Have not yet tested your PR.

<!-- gh-comment-id:4360237229 --> @jimbo-p commented on GitHub (May 1, 2026): > > Thanks for getting a PR out, same issue here. If it helps, share links **are** working for our non-admin users, they seem to only be broken for when an admin opens up a /s link. > > edit: old share links are working, new links are failing. > > [@jimbo-p](https://github.com/jimbo-p) Sorry, I didn't understand what you meant. Is this phenomenon 'old share links are working, new links are failing.' caused by the PR I submitted? No, I had just noticed that a share link generated pre-0.9 still opened up. Anything generated after 0.9 was failing. Have not yet tested your PR.
GiteaMirror commented 2026-05-06 00:17:22 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (May 4, 2026):

Should be addressed in dev, testing wanted here!

<!-- gh-comment-id:4373508715 --> @tjbck commented on GitHub (May 4, 2026): Should be addressed in dev, testing wanted here!
GiteaMirror commented 2026-05-06 00:17:22 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (May 4, 2026):

should be fixed by cde21b9f6d

testing wanted

<!-- gh-comment-id:4374898105 --> @Classic298 commented on GitHub (May 4, 2026): should be fixed by https://github.com/open-webui/open-webui/commit/cde21b9f6dc11575a668484f42440824ec5a4fae testing wanted
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#58851
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?