Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #2197] [BUG]: Token access to workspaces and user in workspace chat logs #1434

New Issue
Closed
opened 2026-02-22 18:24:46 -05:00 by yindo · 1 comment
yindo commented 2026-02-22 18:24:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @mybr4inhurts on GitHub (Aug 29, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2197

How are you running AnythingLLM?

K8s deployment (on premise)

What happened?

Not sure if it is bug or if it's a design choice and additionally not sure if it's on the AnythingLLM side or on the Continue side.

My Observation:
We currently use the Continue IDE Plugin to talk to AnythingLLM via API. AnythingLLM runs as K8s Deployment in the latest Version.
The overall connection works fine, I can chat with my chosen workspace and profit from the vector embeddings in the workspace.
I encountered two strange behaviours though.

  • First: I can chat with any workspace, regardless of being a member or not. Maybe this is caused by using an admin token and will change when the RBAC feature is fully implemented? I would love to be able restrict the token access to workspaces you are not a member of. Ideally the token is automatically restricted according to the user's rights and memberships.
  • Second: The appearing user in the "Workspace Chat" log is always "unknown user" desipte using a personalized API token.
    image

Is there any chance this will be changed in the future? It's not a major deal breaker but an inconvenience to some extend.

Are there known steps to reproduce?

  • setup anythingllm in docker or k8s
  • create an api token
  • fire up VS Code with installed Continue plugin
  • add a config to tell Continue to use your anythingLLM installation via API token

example Continue config:

{
    "title": "Test - AnythingLLM Workspace",
    "provider": "openai",
    "model": "<yourWorkspaceNameHere>",
    "apiBase": "<your-anythingllm-base-url>/api/v1/openai",
    "apiKey": "<your API token>"
}
Originally created by @mybr4inhurts on GitHub (Aug 29, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2197 ### How are you running AnythingLLM? K8s deployment (on premise) ### What happened? Not sure if it is bug or if it's a design choice and additionally not sure if it's on the AnythingLLM side or on the Continue side. My Observation: We currently use the Continue IDE Plugin to talk to AnythingLLM via API. AnythingLLM runs as **K8s Deployment** in the latest Version. The overall connection works fine, I can chat with my chosen workspace and profit from the vector embeddings in the workspace. I encountered two strange behaviours though. * **First**: I can chat with any workspace, regardless of being a member or not. Maybe this is caused by using an admin token and will change when the RBAC feature is fully implemented? I would love to be able restrict the token access to workspaces you are not a member of. Ideally the token is automatically restricted according to the user's rights and memberships. * **Second**: The appearing user in the "Workspace Chat" log is always "unknown user" desipte using a personalized API token. ![image](https://github.com/user-attachments/assets/89008d0f-2fd2-47bf-8a9e-2c786832dfd7) Is there any chance this will be changed in the future? It's not a major deal breaker but an inconvenience to some extend. ### Are there known steps to reproduce? * setup anythingllm in docker or k8s * create an api token * fire up VS Code with installed Continue plugin * add a config to tell Continue to use your anythingLLM installation via API token example Continue config: ```json { "title": "Test - AnythingLLM Workspace", "provider": "openai", "model": "<yourWorkspaceNameHere>", "apiBase": "<your-anythingllm-base-url>/api/v1/openai", "apiKey": "<your API token>" } ```
yindo added the possible bug label 2026-02-22 18:24:46 -05:00
yindo closed this issue 2026-02-22 18:24:46 -05:00
yindo commented 2026-02-22 18:24:46 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Aug 29, 2024):

This is expected, the API user is not a "user" in the sense that they can use the UI, but they can chat with workspaces as if they were since some people use the API as a proxy interface for using AnyhtingLLM in a custom UI implementation.

Then they simulate threads by using the partition key in the workspace/chat endpoint to simulate sessions and such. In fact, in a recent update (https://github.com/Mintplex-Labs/anything-llm/commit/fdc3add53cf12f4a4215b3c251e811d24de2196e#diff-62a2befed6ea340d3946b411495068f1fbfd7a658ecf17ad1935d5d9f231a5fdL199) we added the UI to show this was the "API" invoking this endpoint now

@timothycarambat commented on GitHub (Aug 29, 2024): This is expected, the API user is not a "user" in the sense that they can use the UI, but they can chat with workspaces as if they were since some people use the API as a proxy interface for using AnyhtingLLM in a custom UI implementation. Then they simulate threads by using the `partition` key in the workspace/chat endpoint to simulate sessions and such. In fact, in a recent update (https://github.com/Mintplex-Labs/anything-llm/commit/fdc3add53cf12f4a4215b3c251e811d24de2196e#diff-62a2befed6ea340d3946b411495068f1fbfd7a658ecf17ad1935d5d9f231a5fdL199) we added the UI to show this was the "API" invoking this endpoint now
yindo changed title from [BUG]: Token access to workspaces and user in workspace chat logs to [GH-ISSUE #2197] [BUG]: Token access to workspaces and user in workspace chat logs 2026-06-05 14:40:45 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label possible bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#1434
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?