Closed McCloudS closed 10 months ago
This seems to be by design. The Items/{item_id} route is DELETE only.
Doing a get request for information on a file checks to make sure the userid provided has permissions to access the file. This implementation brings up some issues as the /Users route returns the list of all users in alphabetical order. If the first person on this list doesn't have access to the library this Item is stored in then it will return an error, which is the case in my setup.
An option can be to make a request on startup for a userid that goes through all users and checks for the "IsAdministrator": true value under Policy, then store the Id of that user. This way you don't need to recollect it each time you make a request.
I don't have ready access right now, but maybe /Items/{itemId}/PlaybackInfo can be of use. If that doesn't bear any fruit, I'll need to clean up using your implementation.
The design seems odd if I can use the APIkey to get any userid that I want and do anything with. Unless the APIkey is tied to the userid permissions?
Failing all this, can the userId be pulled from the webhook request that is sent? This way you have a proper reference to the user sending the request.
Closed with merge and small update. Until Jellyfin fixes (in my opinion) how they implement certain api calls, or adds more information to the associated webhook, there's nothing left to do.
Open to feedback, but after beating my head against the wall, the only way I could figure out how to get the filepath from a Jellyfin webhook was:
https://github.com/McCloudS/subgen/blob/b9f69030d2e69ce3497ec39636b97f3d04e15edb/subgen/subgen.py#L248-L249
For some reason, their API doesn't allow calling /Items/{item_id} directly and still requires a userid even though an API key has been provided. The first call finds the Id of the first user on the server and uses that for subsequent Items calls to get the filepath.