GET /api/v1/chats/{id} should return content for admin

[Mara-Li]

In an instance shared between multiple user, the admin can't get the content of a specific conversation using an endpoint, resulting to a 401 response.
But; the admin can get all conversation using the endpoint GET api/v1/chats/all/db.

It leads to inconsistancies, as the admin could read all conversation if the environment key for that is set to true.

Solution: The admin should be able to pull a conversation.

Getting the conversation with the db is pretty long, so it can't be used in production.

[frenzybiscuit]

Alternatively: Don't spy on your users.

[Mara-Li]

In my case, pretty specific i know, it's for a family sharing where every one is warned about this case.
The conversation are stored in the knowledge to create a sort of salf aware model.

Also:

1. Admin have by default access to all conversation
2. Admin also have access to all conversation in the db.

So, if we want to prevents spying even with the admin read rights, the access to the db should be removed. Or the conversation should be cleaned to only have the admin.

My request is just to uniformize the behavior.

[frenzybiscuit]

There is a difference between the sys admin / root user having access to the database and one of the countless open-webui admin having access to every chat O.o.

Family sharing? Even more reason to not have access to the chats.

[frenzybiscuit]

actually this entire conversation has turned creepy AF. Why do you want access to your kids chats?

Please don't say to moderate them. If you don't trust them, revoke their access.

[rgaricano]

In this case the problem isn't trust the childs, is trust the models, but it could be solved with a good & sane prompting.

[Mara-Li]

Why do you even think I have children ????
I share the container to my father, brother, and mother. I don't even have children ???

Also, it's a very specific model. Please, do not make assumption on my project and what I do for it.

ALSO, i talk about endpoint. So your messages are irrelevant, as GET api/v1/chats/all/db works for every admin that have an API key.

It's even worse, as you get access to every chat and contents in the container with only the token;

Also, if you grab the user-id, you can have the conversation with using GET /api/v1/chats/list/user/{user_id}:

And I think more endpoint allow getting the conversation content using userID & chatID. So I don't understand why this endpoint (and it's the only one) is blocked when admin.

[KThompso]

This appears to me to be a general oversight/bug to me as many of the other /api/v1/chats/ endpoints support the admin role, but the support is very inconsistent and has been added piecemeal over time.

RCA

The admin role check was added to a few endpoints starting in early 2024 (when the admin panel user chat viewing feature was added), but the GET /{id} endpoint was overlooked. For some reason, the admin bypass was added to the /share/{share_id} endpoint at the same time (commit f64ac32), which appears to have been used as a workaround for the admin panel.

Immediate Fix

Add an admin role check to the get_chat_by_id endpoint to match the pattern used in other endpoints:

@router.get("/{id}", response_model=Optional[ChatResponse])
async def get_chat_by_id(id: str, user=Depends(get_verified_user)):
    if user.role == "admin" and ENABLE_ADMIN_CHAT_ACCESS:
        chat = Chats.get_chat_by_id(id)
    else:
        chat = Chats.get_chat_by_id_and_user_id(id, user.id)
    # ... rest of function

Should probably also update the admin panel to use this endpoint and possibly adjust the share endpoint to be more internally consistent.

Broader Issue

Admin support is really inconsistent across the /api/v1/chats/ endpoints:

This might be a good time to review the admin support across the API for consistency, or even take a step back and reevaluate the permissions model for the API entirely.

Workaround

@Mara-Li - Regarding accessing all user chats as an admin. There's appears to be a workaround through the /api/v1/chats/share/{chat_id} endpoint. Admins can use /api/v1/chats/share/{chat_id} (instead of .../chats/{chat_id}) to access any chat by its ID, whether it's shared or not. This is how the admin panel currently views user chats. Provided ENABLE_ADMIN_CHAT_ACCESS is enabled (which it is by default).

Happy to submit an issue and/or PR to fix the immediate issue or help with a broader consistency review if the maintainers would like.