User can see other users' messages in convo history

[krahnikblis]

have been using version 0.7.2 for my team in a corp environment - LC installed using Docker on a VM and using our Azure OpenAI resource. last week my boss asked me why she could see her boss' (she thinks, or one of her peers) messages in her own history. this spurred me to update to the latest LC (docker rmi > git pull > docker compose pull > update .env and yamls > docker compose up -d > now v0.8.0-rc2), she reports the same issue still.

i don't see anyone else's conversations in my own history, i.e., i can't independently verify or replicate.
i asked her to use the "search messages" box to search for a term appearing in one of the suspect conversations (in this case, "Deeper Investigation is Next" was a term in a suspect message), she got no results - so she can see the other convo, but Melei can't, which i find odd but potentially helpful in troubleshooting?

• however, now when i try to search my own message history for anything at all, no results, so i guess the update broke the search capability??

having no admin portal in the UI, i'm at a loss for what to do next. how can i search the message history across all users to find which user actually typed the thing? i want to rule out some more obvious explanations like:

• someone using her credential? (check IP address, etc.)
• somehow her user ID in the backend has a clash with another user's? (check unique ids against user names)
• somehow a header in HTTP calls contains an ID/cookie/something which links together conversations and users inappropriately?

how else can i troubleshoot? how can i actually peruse the history/conversations of all users to get closer to the culprit?

[danny-avila]

Thanks for the detailed report. Cross-user conversation visibility isn't architecturally possible in LibreChat, our codebase has strict user isolation that is integral to every request that you can verify by reviewing the authentication and database query layers.

For troubleshooting, I'd suggest:

1. Fix search first: Run npm run reset-meili-sync to re-index conversations after the version jump (0.7.2 → 0.8.0-rc2 requires this)

• Here's how to run scripts depending on your environment:
  - https://www.librechat.ai/docs/configuration/authentication#create-user-script

2. Verify the issue: Once search works, have your boss log out and log back in, search for specific terms from the "foreign" conversations to confirm they actually appear in her history

3. Check obvious causes:

   • Shared browser/device with saved credentials
   • Someone else using her login
   • Browser cache/session issues (try incognito mode)

4. Database verification: If you have database access, you can query the conversations table to check which user field owns specific conversation IDs

• You can even use a Mongo MCP server + LibreChat to verify: https://github.com/mongodb-js/mongodb-mcp-server
• https://www.librechat.ai/docs/features/mcp

The lack of admin UI is a known limitation and we are actively working on it but the database queries will give you definitive answers about conversation ownership. Most likely this is a client-side caching issue or shared authentication rather than a backend data leak.

Let me know what the search re-indexing reveals.

[krahnikblis]

thanks for the quick response!

1. "docker-compose exec api npm run reset-meili-sync" was successful, and search now works for me (thanks for the quick fix!)

• is there anything else i should have done during upgrade? e.g., i saw some errors in the docker logs and/or log files, which when i searched here, i found a note from you that OPENAI_TITLE_MODEL had been deprecated (yet it's still found in the repo's current .env example) - do i need to clean out any old .env settings and/or reformat anything in the yamls?

2. i just now set up mogo-express per https://www.librechat.ai/blog/2023-11-30_mongoexpress and it appears the conversation in question belongs to my boss' user id and it's almost a month old... the way the user in question addresses the AI seems consistent with her other confirmed messages, and not like any of her suspected peers/boss way of talking to it, but still she doesn't remember - at any rate i reset her password just in case, and asked her to let me know ASAP for any future incidents so i can check logs for IP addresses before they're auto-deleted... (would be helpful if Mongo stored user agent, IP, etc in the sessions or conversations tables - traces like that are very helpful in checking for abuse of credentials...).

at any rate, since i can't come up with any more evidence (and what i can find points to the application behaving as designed) i'll close this - i'll comment back here if anything more concrete is discovered - thanks again for pointing me to the things needed to dig deeper, and i look forward to the admin portal's release!