mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement]: API to get user information by email. #1705
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#1705
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 @izyspania on GitHub (Feb 2, 2024).
Describe the feature/enhancement
Would be nice to have an API for getting user information by email, i have an external database with emails that i want to use for allowing registration or enable some features for the user , like "Downloading" or setting the user inactive via API.
PATCH http://abs.example.com/api/users/<EMAIL>Thanks.
@advplyr commented on GitHub (Feb 2, 2024):
I don't understand the feature request. Can you elaborate?
@izyspania commented on GitHub (Feb 2, 2024):
I wrote on the discord about it , so i have an external database with user information (email , name , home address etc) that is used and managed by some other framework and i cant add extra info to it.
I want to be able to do something like this: External DB (other framework) --> Delete an user from there (that has its own userIDs) -- > Check if the user email address has an user on ABS via API --> (receive the userID ) - Set user inactive , delete it (or whatever) in ABS via API using the userID (or if its possible to do it directly with the email address that would work too)
The problem is that i dont have a way to check/manipulate some user using the email of the user or get his ABS userID using his email.
Using user names is not an option because people will register via OpenID and you can have duplicate usernames if people have the same name.
Edit: I didnt check yet but im assuming that email addresses are unique, at least if using OpenID for registration you cant have same email if im correct.
@advplyr commented on GitHub (Feb 2, 2024):
I'm still not sure I understand but there is already an API endpoint for you to get all users. https://api.audiobookshelf.org/#get-all-users
Then you can use that to find one with a matching email
@izyspania commented on GitHub (Feb 2, 2024):
So i have to pull all the users all the time i want to do this something like this? I thought you could add something like
PATCH http://abs.example.com/api/users/**<EMAIL>**to change the user info / or a GET to get userID from the email.@advplyr commented on GitHub (Feb 2, 2024):
I don't understand what you are trying to do and what would need to be done in Abs. Maybe someone else can step in to help explain
@nichwall commented on GitHub (Feb 3, 2024):
The main request is to be able to get a subset of users from the server instead of requesting all users in the database and filtering on the client (how it is currently done using the
/usersroute).Adding filtering/sorting on the users column would help make user management feature requests simpler, such as https://github.com/advplyr/audiobookshelf/issues/2066.
I'm not sure if the
/users/:idPATCH route to update a user needs to (or should?) be changed. Making a batch edit for users would fall under a different feature request.Edit to add: I realize this is a very long response to the discussion, but hopefully includes information for both sides.
Some implementation ideas:
This could be done by allowing extra information to be passed as part of the request, similar to how the "Update a user" is done (the following example is from the API docs).
I'm not sure how hard changing the
/usersroute to support filtering or sorting without a breaking change would work, but my thought is that it could be something like the API accepts the name of the column to search over (emailcolumn in this case) and allowed values. In the case of something likeUUIDorVARCHAR, it looks for an exact match, and theDATETIMEcolumns could have a min/max value to filter by. Optionally, there could also be asortentry which determines how the result is returned (defaults byidor something).If additional data is not provided to the API on the
/usersroute, then by default it returns all users using the existing method.An example of how this could be formatted is something like:
Main Issues with Idea
The main confusion that I could see occurring is people mixing up the
minandmaxvalues, but that would be handled by documentation and experimentation.If filtering and sorting of users is added to the API, there will likely be requests to filter and sort on the JSON columns, which will be more involved and probably not supported for a while due to complexity of filtering on fields within a JSON column until/if the data model changes to be better searched.
Related
The current
userstable from 2.7.0 is included below as a reference.@izyspania commented on GitHub (Feb 3, 2024):
Something like:
--- just change user settings using the email directly
curl -X PATCH "https://abs.example.com/api/users/user@gmail.com"
-H "Authorization: Bearer exJhbGciOiJI6IkpXVCJ9.eyJ1c2Vyi5NDEyODc4fQ.ZraBFohS4Tg39NszY"
-H "Content-Type: application/json"
-d '{"username": "bob", "password": "12345"}'
OR
--- get user ID (or all the user information) matching that email so i can use it after to update user information.
curl "https://abs.example.com/api/users/user@gmail.com"
-H "Authorization: Bearer exJhbGciOiJI6IkpXVCJ9.eyJ1c2Vyi5NDEyODc4fQ.ZraBFohS4Tg39NszY" -- return the userID (UUID) or all the user information like when using the userID(UUID).
{
"id": "root",
}
using this method has be same for deleting a user:
curl -X DELETE "https://abs.example.com/api/users/user@gmail.com"
-H "Authorization: Bearer exJhbGciOiJI6IkpXVCJ9.eyJ1c2Vyi5NDEyODc4fQ.ZraBFohS4Tg39NszY"
OR
--- we can have a different API link to do just that.
curl "https://abs.example.com/api/users/email/user@gmail.com"
-H "Authorization: Bearer exJhbGciOiJI6IkpXVCJ9.eyJ1c2Vyi5NDEyODc4fQ.ZraBFohS4Tg39NszY" -- return the userID (UUID) or all the user information like when using the userID(UUID).
{
"id": "root",
}
I hope its clear now, maybe there is a better way to do this than what i wrote but this is what i thought of atm.
It didnt cross my mind getting all the users first and then matching the email , that sounds decent as an "workaround" but i think something to do this directly with the API would be great, getting all the users and filter them again its a waste of server resources if you have many users but i guess the process wont happen very often but it looks messy.
Thanks nichwall for trying to explain but i am assuming that each user has a unique email so the return should be only for one user.