api key exposure when opening a pdf

[horstepipe 429]

Hello

from my point this is a no go - sure one could argument that you get the same if you examine client logs, but how this is being done here is way too easy:

if you open a pdf on IOS the app directs to browser with a link to the file with the api key - so the user can share that link to whoever he wants…

 

[Luke 42709]

Hi, audio video playback also puts the api key in the media url.

 Ultimately I think what should happen is a new token should be created based on the existing one but that only has permission to do that one thing.

[horstepipe 429]

I never use Emby per browser so I wasn’t aware about that.

What do you mean by „audio video playback“? Audio and video playback?

 

[Luke 42709]

On 5/23/2026 at 6:13 AM, horstepipe said:

I never use Emby per browser so I wasn’t aware about that.

What do you mean by „audio video playback“? Audio and video playback?

 

I mean with the url that it sends to the browser audio or video player.

[horstepipe 429]

On 5/23/2026 at 1:54 AM, Luke said:

Hi, audio video playback also puts the api key in the media url.

 Ultimately I think what should happen is a new token should be created based on the existing one but that only has permission to do that one thing.

I can't reproduce what you say.
Whatever I play I only see item?id and serverID= in link path. But when opening a pdf on IOS now, I see the api key in the link path and I don't see a way to stop that behavior.
So I need to remove my books libraries now, don't see another option.

BR

Edited June 7 by horstepipe

[Luke 42709]

I mean like if you inspect the video player using the browser debug features.

[horstepipe 429]

If one does that, sure. Like if one examines client logs.

but as initially said the way this is handled now is too obvious.