mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[GH-ISSUE #12610] feat: API: Get a user by email #55322
Reference in New Issue
Block a user
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?
Originally created by @mrakgr on GitHub (Apr 8, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12610
Check Existing Issues
Problem Description
I am trying to integrate the Open WebUI with the backend for our website, and I find myself badly missing a certain feature. Namely, I want to be able to get a user by his email instead of just entire list or just the id. When a user clicks on the Open WebUI tab on our website, that's when his account actually gets created. First, a new user gets created, and then the direct connection to the Tao Ceti API is set.
But if the user is already there, I get an error and skip the step of updating the connection.
This isn't right; a robust implementation would check whether the user already exists before doing the above steps. Moreover, the API token to which the user's password is keyed might change if the user changes his subscription, so I need to do that anyway in order to check whether to update the password for his Open WebUI account. Right now, the only choice is to get the entire list of users. This could get hairy quickly if we ever get a significant number of users.
Desired Solution you'd like
Add an API endpoint to get a user by his email.
Alternatives Considered
Getting the entire list.
Additional Context
No response
@mrakgr commented on GitHub (Apr 8, 2025):
Actually, I didn't realize that it's possible to use the signin endpoint to get the id and the token before I made this request, so that might suffice. I did find a security vulnerability in the process of this.
@mrakgr commented on GitHub (Apr 8, 2025):
No, the signins endpoint require a password, which makes them imperfect, as the user could potentially change his password. I cannot use that method as an admin to check for whether the user exists either. It would be enough for all my needs if it was impossible to change the password once it has been created, but a robust implementation wouldn't require it.