[GH-ISSUE #2904] feat: authentication control for shared chats #100055

New Issue

GiteaMirror · 2026-05-17T21:59:58-05:00

GiteaMirror commented

2026-05-17 21:59:58 -05:00

Originally created by @Syakyr on GitHub (Jun 7, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/2904

Is your feature request related to a problem? Please describe.
Current implementation of sharing chats would require the recipient to be logged in, thus making it difficult to share to non-users on-the-fly.
I had considered reporting this as a bug due to #2664 seeming to suggest that this feature was once available, but perhaps due to the implementation of single-user vs multi-user implementation, it might have forced API to be redirected /auth any time an unauthorized user accesses the service.

I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats.

Describe the solution you'd like
The shared bubble would show a toggle of whether the chat link is to be public. If it is, it doesn't require any authentication to look at the chat.

Describe alternatives you've considered
Create a user account just to view the shared chat, but since role implementation are not granular (model whitelisting only affects users, and no separate roles just for viewers, or budget restrictions for each user, etc.), this is currently not viable.

Originally created by @Syakyr on GitHub (Jun 7, 2024). Original GitHub issue: https://github.com/open-webui/open-webui/issues/2904 **Is your feature request related to a problem? Please describe.** Current implementation of sharing chats would require the recipient to be logged in, thus making it difficult to share to non-users on-the-fly. I had considered reporting this as a bug due to #2664 seeming to suggest that this feature was once available, but perhaps due to the implementation of single-user vs multi-user implementation, it might have forced API to be redirected `/auth` any time an unauthorized user accesses the service. I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats. **Describe the solution you'd like** The shared bubble would show a toggle of whether the chat link is to be public. If it is, it doesn't require any authentication to look at the chat. **Describe alternatives you've considered** Create a user account just to view the shared chat, but since role implementation are not granular (model whitelisting only affects users, and no separate roles just for viewers, or budget restrictions for each user, etc.), this is currently not viable.

GiteaMirror commented

2026-05-17 21:59:59 -05:00

@silentoplayz commented on GitHub (Jun 7, 2024):

I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats.

Related - #2890 (Public Access Option), but I believe your request should remain open along side it.

@silentoplayz commented on GitHub (Jun 7, 2024): > I have tested behind Nginx proxy and localhost URL, and both resulted in the same outcome of requiring authentication to see shared chats. Related - #2890 (Public Access Option), but I believe your request should remain open along side it.

GiteaMirror commented

2026-05-17 21:59:59 -05:00

@Syakyr commented on GitHub (Jun 7, 2024):

I've read #2890 (didn't catch the issue as I was searching for "chats" for duplicates before opening this issue), and I hope that we eventually have those features. I suppose what I'm proposing here is of a smaller scale since just to casually share the results to other people. I suppose something to add to this feature is an expiry date to the links just in case one doesn't intend to share the page indefinitely.

@Syakyr commented on GitHub (Jun 7, 2024): I've read #2890 (didn't catch the issue as I was searching for "chats" for duplicates before opening this issue), and I hope that we eventually have those features. I suppose what I'm proposing here is of a smaller scale since just to casually share the results to other people. I suppose something to add to this feature is an expiry date to the links just in case one doesn't intend to share the page indefinitely.

GiteaMirror commented

2026-05-17 21:59:59 -05:00

@RexWzh commented on GitHub (Aug 14, 2024):

A temperate solution, if you wish to share few chats with others. A dummy way.

Visit your shared link.
In your browser, press Ctrl + S to save the HTML file.
Upload the saved HTML file to the server, for example, to /var/www/shared_chats.
chmod 755 -R /var/www/shared_chats to avoid permissions issue.

Configure your Nginx server as follows:

server {
    listen 443 ssl;
    server_name {your-shared-url};
    ssl_certificate /etc/letsencrypt/live/{your-shared-url}/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/{your-shared-url}/privkey.pem;
    root /var/www/shared_chats;
}
server {
    listen 80;
    server_name {your-shared-url};
    rewrite ^(.*)$ https://$host$1 permanent;
}

An example chat:
https://shared-chats.cubenlp.com/gpt4o.html

@RexWzh commented on GitHub (Aug 14, 2024): A temperate solution, if you wish to share few chats with others. A dummy way. 1. Visit your shared link. 2. In your browser, press `Ctrl + S` to save the HTML file. 3. Upload the saved HTML file to the server, for example, to `/var/www/shared_chats`. 4. `chmod 755 -R /var/www/shared_chats` to avoid permissions issue. Configure your Nginx server as follows: ```bash server { listen 443 ssl; server_name {your-shared-url}; ssl_certificate /etc/letsencrypt/live/{your-shared-url}/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/{your-shared-url}/privkey.pem; root /var/www/shared_chats; } server { listen 80; server_name {your-shared-url}; rewrite ^(.*)$ https://$host$1 permanent; } ``` An example chat: [https://shared-chats.cubenlp.com/gpt4o.html](https://shared-chats.cubenlp.com/gpt4o.html)

GiteaMirror commented

2026-05-17 22:00:00 -05:00

@CallumCarmicheal commented on GitHub (Jan 31, 2025):

Is there any progress being made on this issue? Currently there is a way to publically share the chat conversation with the public through Open-WebUI's community website although this still involves uploading chat context and data to an external service that is not controlled by the hosted instance. The solution proposed by @RexWzh only works for simple prompts where multiple choices / generations are not present. Neither are attachments accessible through a saved page.

Is there any further interest in this for privacy concerns or is this issue now being ignored because the save to community feature exists?

@CallumCarmicheal commented on GitHub (Jan 31, 2025): Is there any progress being made on this issue? Currently there is a way to publically share the chat conversation with the public through Open-WebUI's community website although this still involves uploading chat context and data to an external service that is not controlled by the hosted instance. The solution proposed by @RexWzh only works for simple prompts where multiple choices / generations are not present. Neither are attachments accessible through a saved page. Is there any further interest in this for privacy concerns or is this issue now being ignored because the save to community feature exists?

GiteaMirror commented

2026-05-17 22:00:01 -05:00

@ddkedr commented on GitHub (Mar 28, 2025):

Up! Really need this

@ddkedr commented on GitHub (Mar 28, 2025): Up! Really need this

GiteaMirror commented

2026-05-17 22:00:02 -05:00

@skobkin commented on GitHub (Mar 30, 2025):

Can agree with others above. For me personally it makes no sense to use community sharing. I need sharing which is available on my instance so I can:

Control when to stop sharing it from the chat itself (like it's implemented now, but doesn't work yet without authentication)
Use it in the LAN (for my home installation) or in the network which accessible only via VPN (for my work installation)

Asking people to register isn't too convenient too since:

It's a bit much to ask
In some cases registration is just disabled

@skobkin commented on GitHub (Mar 30, 2025): Can agree with others above. For me personally it makes no sense to use community sharing. I need sharing which is available on my instance so I can: - Control when to stop sharing it from the chat itself (like it's implemented now, but doesn't work *yet* without authentication) - Use it in the LAN (for my home installation) or in the network which accessible only via VPN (for my work installation) Asking people to register isn't too convenient too since: - It's a bit much to ask - In some cases registration is just disabled

GiteaMirror commented

2026-05-17 22:00:02 -05:00

@navilg commented on GitHub (Apr 23, 2025):

Need this feature. We may think of implementing it with below features

Option to share with temporary password
Option to share with an expiry date
Option to share it without password
Option to revoke the shared chat
Option to restrict usage of LLM models on shared chats

@navilg commented on GitHub (Apr 23, 2025): Need this feature. We may think of implementing it with below features 1. Option to share with temporary password 2. Option to share with an expiry date 3. Option to share it without password 4. Option to revoke the shared chat 5. Option to restrict usage of LLM models on shared chats

GiteaMirror commented

2026-05-17 22:00:03 -05:00

@janaki-sasidhar commented on GitHub (Jun 6, 2025):

Need this feature

@janaki-sasidhar commented on GitHub (Jun 6, 2025): Need this feature

GiteaMirror commented

2026-05-17 22:00:03 -05:00

@silentoplayz commented on GitHub (Jun 7, 2025):

Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to Read access would prevent users from cloning the chat when viewing it via the shared link, while Write access would allow them to clone the chat into their own chats list.

It's a +1 from me for being able (in the future of course) to share chats without requiring someone to sign up to view it.

@silentoplayz commented on GitHub (Jun 7, 2025): Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to `Read` access would prevent users from cloning the chat when viewing it via the shared link, while `Write` access would allow them to clone the chat into their own chats list. It's a +1 from me for being able (in the future of course) to share chats without requiring someone to sign up to view it.

GiteaMirror commented

2026-05-17 22:00:04 -05:00

@silentoplayz commented on GitHub (Jun 7, 2025):

Need this feature. We may think of implementing it with below features

1. Option to share with temporary password

2. Option to share with an expiry date

3. Option to share it without password

4. Option to revoke the shared chat

5. Option to restrict usage of LLM models on shared chats

By the way, if you weren't aware, there's an option to revoke the shared chat URL within the Share modal of a chat. This option becomes available if you revisit the Share modal of the chat after initially generating the share link.

@silentoplayz commented on GitHub (Jun 7, 2025): > Need this feature. We may think of implementing it with below features > > 1. Option to share with temporary password > > 2. Option to share with an expiry date > > 3. Option to share it without password > > 4. Option to revoke the shared chat > > 5. Option to restrict usage of LLM models on shared chats By the way, if you weren't aware, there's an option to revoke the shared chat URL within the `Share` modal of a chat. This option becomes available if you revisit the `Share` modal of the chat after initially generating the share link. ![Image](https://github.com/user-attachments/assets/8e6aa3aa-8b26-4628-8e99-8f518ab03b8d)

GiteaMirror commented

2026-05-17 22:00:04 -05:00

@xindoo commented on GitHub (Jun 18, 2025):

This feature is something I urgently need. It would greatly improve my experience. Please consider prioritizing its development.

@xindoo commented on GitHub (Jun 18, 2025): This feature is something I urgently need. It would greatly improve my experience. Please consider prioritizing its development.

GiteaMirror commented

2026-05-17 22:00:04 -05:00

@QriDoki commented on GitHub (Jul 23, 2025):

Need this feature

@QriDoki commented on GitHub (Jul 23, 2025): Need this feature

GiteaMirror commented

2026-05-17 22:00:05 -05:00

@jasverma-hub commented on GitHub (Jul 23, 2025):

Is there any progress on this feature?

@jasverma-hub commented on GitHub (Jul 23, 2025): Is there any progress on this feature?

GiteaMirror commented

2026-05-17 22:00:06 -05:00

@latel commented on GitHub (Aug 1, 2025):

Is there any progress on this feature?

@latel commented on GitHub (Aug 1, 2025): Is there any progress on this feature?

GiteaMirror commented

2026-05-17 22:00:06 -05:00

@skobkin commented on GitHub (Aug 1, 2025):

Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to Read access would prevent users from cloning the chat when viewing it via the shared link, while Write access would allow them to clone the chat into their own chats list.

I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense.
Cloning is basically creating a copy which belongs to you. To copy something you need to be able to read it.

@skobkin commented on GitHub (Aug 1, 2025): > Personally, I'd like to see an access control modal with a read/write toggle for shared chats. Setting it to `Read` access would prevent users from cloning the chat when viewing it via the shared link, while `Write` access would allow them to clone the chat into their own chats list. I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense. Cloning is basically creating a copy which belongs to you. To copy something you need to be able to **read** it.

GiteaMirror commented

2026-05-17 22:00:06 -05:00

@silentoplayz commented on GitHub (Aug 4, 2025):

I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense.
Cloning is basically creating a copy which belongs to you. To copy something you need to be able to read it.

Never did I mention that cloning a chat should require "write" permission on the chat. It'd be an optional permission. Perhaps my original message didn't get the point across as clearly as I would've hoped, so I will try to break things down for easier digestion. Say for example, I generated a share link for a chat I want to share with a friend that has an account on my Open WebUI instance. I could be given the option to keep the chat permission with read+write access, or adjust it to have only read access before (or even after) generating the chat link for sharing.

Read+write access = Default behavior and the same behavior we already see displayed for shared chats in Open WebUI.
For example, if my friend visits the URL for the shared chat, they will be able to read the chat, but also see a Clone button at the bottom center of the page to clone the chat into their own chats sidebar on their own account.

Only "read" access = That button to clone the chat into my friend's own account becomes unavailable for them. It doesn't exist on the shared chat's page for anybody and keeps the chat from being spread around like a virus.

I hope this clears up any cloudy vision of what I am hoping to see come to Open WebUI for shared chats!

@silentoplayz commented on GitHub (Aug 4, 2025): > I'm not sure why cloning should require "write" permission on the chat. This doesn't make any sense. > Cloning is basically creating a copy which belongs to you. To copy something you need to be able to **read** it. Never did I mention that cloning a chat **should require** "write" permission on the chat. It'd be an optional permission. Perhaps my original message didn't get the point across as clearly as I would've hoped, so I will try to break things down for easier digestion. Say for example, I generated a share link for a chat I want to share with a friend that has an account on my Open WebUI instance. I could be given the option to keep the chat permission with read+write access, or adjust it to have only read access before (or even after) generating the chat link for sharing. Read+write access = Default behavior and the same behavior we already see displayed for shared chats in Open WebUI. For example, if my friend visits the URL for the shared chat, they will be able to read the chat, but also see a `Clone` button at the bottom center of the page to clone the chat into their own chats sidebar on their own account. Only "read" access = That button to clone the chat into my friend's own account becomes unavailable for them. It doesn't exist on the shared chat's page for anybody and keeps the chat from being spread around like a virus. I hope this clears up any cloudy vision of what I am hoping to see come to Open WebUI for shared chats!

GiteaMirror commented

2026-05-17 22:00:07 -05:00

@skobkin commented on GitHub (Aug 4, 2025):

@silentoplayz I'm sorry, but it still doesn't make any sense to me.

The first part of your message contradicts with the second from my PoV.

First:

Never did I mention that cloning a chat should require "write" permission on the chat

Second:

Read+write access = <...> they will be able to read the chat, but also see a Clone button at the bottom center of the page to clone the chat
Only "read" access = That button to clone the chat into my friend's own account becomes unavailable for them

So, in summary:

Read + Write: "Clone" button available.
Read: "Clone" button unavailable.

The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat.

What am I missing?

@skobkin commented on GitHub (Aug 4, 2025): @silentoplayz I'm sorry, but it still doesn't make any sense to me. The first part of your message contradicts with the second from my PoV. First: > Never did I mention that cloning a chat should require "write" permission on the chat Second: > Read+write access = <...> they will be able to read the chat, but **also see a Clone button** at the bottom center of the page to clone the chat > Only "read" access = That button to clone the chat into my friend's own account **becomes unavailable** for them So, in summary: `Read` + `Write`: "Clone" button available. `Read`: "Clone" button unavailable. The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat. What am I missing?

GiteaMirror commented

2026-05-17 22:00:08 -05:00

@silentoplayz commented on GitHub (Aug 4, 2025):

The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat.

What am I missing?

I think you're seeing this all too pedantically. Read+Write access = You have read access to read the contents of the shared chat, but you can also clone said chat into your own account. Read access = The "clone" button on any shared chat's page disappears, leaving users the ability to still READ the contents of the chat (view it with their eyeballs), but creating a copy/clone of this chat into your own account is not an option anymore. This is as simple as it can get. And if you think anything else while hearing this come from me and still decide to contradict my words, then you're tripping over a log you laid out before yourself; not me.

@silentoplayz commented on GitHub (Aug 4, 2025): > The difference I see here is that "write" permission adds a "Clone" button. Which makes no sense since you shouldn't need a write permission to READ the content. And when you're cloning, you're creating a NEW chat from YOUR account. Which you should be able to do regardless of your permissions in the shared chat. > > What am I missing? I think you're seeing this all too pedantically. Read+Write access = You have read access to read the contents of the shared chat, but you can also clone said chat into your own account. Read access = The "clone" button on any shared chat's page disappears, leaving users the ability to still READ the contents of the chat (view it with their eyeballs), but creating a copy/clone of this chat into your own account is not an option anymore. This is as simple as it can get. And if you think anything else while hearing this come from me and still decide to contradict my words, then you're tripping over a log you laid out before yourself; not me.

GiteaMirror commented

2026-05-17 22:00:09 -05:00

@skobkin commented on GitHub (Aug 4, 2025):

@silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker.

"read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place.
"write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore.
I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user expects from it. If you make it do unexpected things, it'll become unfriendly.

If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.

@skobkin commented on GitHub (Aug 4, 2025): @silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker. - "read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place. - "write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore. - I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user **expects** from it. If you make it do unexpected things, it'll become unfriendly. If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.

GiteaMirror commented

2026-05-17 22:00:12 -05:00

@silentoplayz commented on GitHub (Aug 4, 2025):

@silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker.

"read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place.

"write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore.

I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user expects from it. If you make it do unexpected things, it'll become unfriendly.

If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log.

Fair enough. I can see both sides of the argument and I wasn't thinking logically about the whole issue. I do apologize for the tone I gave towards the end of my previous response to you. My reasoning was sound to me with my way of thinking, but may not be sound in your books. That's okay. I still have much to learn and you've taught me something today.

@silentoplayz commented on GitHub (Aug 4, 2025): > @silentoplayz Okay, first things first. I'm sorry if it's a language barrier since I'm not a native English speaker. > > - "read" access should be applied and implied by default. Otherwise there's no point in sharing the chat in the first place. > - "write" usually means (and expected to mean) an ability to CHANGE the object. It applies to relation between an account or other entity (like sharing link) and the target object and used to resolve user's permission in the process of authorization. So if you suggest to add "write" permission it should allow to MODIFY the original chat. Which doesn't make sense in case of "sharing". It's more like converting a chat to a channel and inviting someone there. In this case it's an invite link, not a sharing link anymore. > - I'm not trying to be pedantic, I'm trying to apply basic logic and semantics to what you suggest. And it doesn't add up in the end. UI should behave in a logical way and do what user **expects** from it. If you make it do unexpected things, it'll become unfriendly. > > If you see the flaw in my logic, please point it out instead of saying that I'm tripping over a log. Fair enough. I can see both sides of the argument and I wasn't thinking logically about the whole issue. I do apologize for the tone I gave towards the end of my previous response to you. My reasoning was sound to me with my way of thinking, but may not be sound in your books. That's okay. I still have much to learn and you've taught me something today.

GiteaMirror commented

2026-05-17 22:00:16 -05:00

@skobkin commented on GitHub (Aug 4, 2025):

@silentoplayz No offence taken. I'm glad that I was able to explain how did I come to that conclusion 🤝 .

@skobkin commented on GitHub (Aug 4, 2025): @silentoplayz No offence taken. I'm glad that I was able to explain how did I come to that conclusion 🤝 .

GiteaMirror commented

2026-05-17 22:00:19 -05:00

@silentoplayz commented on GitHub (Aug 13, 2025):

https://github.com/open-webui/open-webui/pull/16367

@silentoplayz commented on GitHub (Aug 13, 2025): https://github.com/open-webui/open-webui/pull/16367

GiteaMirror commented

2026-05-17 22:00:23 -05:00

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

more granular sharing permissions were added recently, only thing missing now would be truly public sharing

@Classic298 commented on GitHub (May 17, 2026): more granular sharing permissions were added recently, only thing missing now would be truly public sharing

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#100055