starred/jellyfin

Fork 0

mirror of https://github.com/jellyfin/jellyfin.git synced 2026-01-23 23:20:51 +01:00

Refactor "Copy Stream URL" to not leak the user's session API key #5360

New issue

Open

opened 2025-12-22 01:35:38 +01:00 by backuprepo · 4 comments

backuprepo commented

2025-12-22 01:35:38 +01:00

Owner

Originally created by @sqlstatement on GitHub (Jan 4, 2024).

The way this currently works is that, when you share the URL using the "Copy Stream URL" button in the Jellyfin Web UI, it copies the stream link and appends the API key (access token) of the current user session.

My proposal would be to modify that mechanism to create a new API key, with permissions to only view the object that was actually shared.

This has two reasons:

Sharing the link with people, regardless of trust is dangerous as the API key can be used to log in as that user
Embedding the content on websites etc. is very impractical, because the API key currently expires once the session ends (the user logs out)

My idea for an implementation would be as follows: When using the "Copy Stream URL" feature, a new key with access to only that object is generated. I would also add a small selector box where the user can choose how long the link should be valid, to avoid any potential abuse/unwanted link sharing. This approach should not be a breaking change, as the user authentication and authorization mechanisms will not be changed.

I'm happy to discuss the details and would be ready to make the needed changes to the codebase in a pull request once I receive the all clear that the feature is wanted and fine to add.

Originally created by @sqlstatement on GitHub (Jan 4, 2024). The way this currently works is that, when you share the URL using the "Copy Stream URL" button in the Jellyfin Web UI, it copies the stream link and appends the API key (access token) of the current user session. My proposal would be to modify that mechanism to create a new API key, with permissions to only view the object that was actually shared. This has two reasons: * Sharing the link with people, regardless of trust is dangerous as the API key can be used to log in as that user * Embedding the content on websites etc. is very impractical, because the API key currently expires once the session ends (the user logs out) My idea for an implementation would be as follows: When using the "Copy Stream URL" feature, a new key with access to only that object is generated. I would also add a small selector box where the user can choose how long the link should be valid, to avoid any potential abuse/unwanted link sharing. This approach should not be a breaking change, as the user authentication and authorization mechanisms will not be changed. I'm happy to discuss the details and would be ready to make the needed changes to the codebase in a pull request once I receive the all clear that the feature is wanted and fine to add.

backuprepo added the

security

label 2025-12-22 01:35:38 +01:00

backuprepo commented

2025-12-22 01:35:40 +01:00

Author

Owner

@sqlstatement commented on GitHub (Jan 7, 2024):

Looks like this will be a much bigger change than anticipated, since the current API key implementation does not allow for fine grained control via its permission system. I'll have to see if this is even going to be possible.

@sqlstatement commented on GitHub (Jan 7, 2024): Looks like this will be a much bigger change than anticipated, since the current API key implementation does not allow for fine grained control via its permission system. I'll have to see if this is even going to be possible.

backuprepo commented

2025-12-22 01:35:41 +01:00

Author

Owner

@sqlstatement commented on GitHub (Jan 17, 2024):

From what I can see, API keys currently have unrestricted permissions, so it seems like my initial worry about this being a bigger change than anticipated has been confirmed. (https://github.com/jellyfin/jellyfin/blob/master/Jellyfin.Api/Auth/DefaultAuthorizationPolicy/DefaultAuthorizationHandler.cs#L52)

I'll do some more research to see how much needs to be changed, but the current Authorization Handlers will need some work, at the very least to remove and replace the hardcoded API key part

@sqlstatement commented on GitHub (Jan 17, 2024): From what I can see, API keys currently have unrestricted permissions, so it seems like my initial worry about this being a bigger change than anticipated has been confirmed. (https://github.com/jellyfin/jellyfin/blob/master/Jellyfin.Api/Auth/DefaultAuthorizationPolicy/DefaultAuthorizationHandler.cs#L52) I'll do some more research to see how much needs to be changed, but the current Authorization Handlers will need some work, at the very least to remove and replace the hardcoded API key part

backuprepo commented

2025-12-22 01:35:43 +01:00

Author

Owner

@TheRainstorm commented on GitHub (May 21, 2024):

I'm happy to discuss the details and would be ready to make the needed changes to the codebase in a pull request once I receive the all clear that the feature is wanted and fine to add.

It's a useful feature, especially for VRChat! I used to share my video url in VRChat without knowing its potential risk. I also found someone with a similar need: https://www.reddit.com/r/VRchat/comments/18ira6e/self_hosting_videos_from_home_with_jellyfin_cdn/

I would appreciate it if you could implement it. 👍

@TheRainstorm commented on GitHub (May 21, 2024): > I'm happy to discuss the details and would be ready to make the needed changes to the codebase in a pull request once I receive the all clear that the feature is wanted and fine to add. It's a useful feature, especially for VRChat! I used to share my video url in VRChat without knowing its potential risk. I also found someone with a similar need: https://www.reddit.com/r/VRchat/comments/18ira6e/self_hosting_videos_from_home_with_jellyfin_cdn/ I would appreciate it if you could implement it. 👍

backuprepo commented

2025-12-22 01:35:45 +01:00

Author

Owner

@silverwolf04 commented on GitHub (Jul 7, 2025):

Getting this refactored to be more secure would be great. I had stumbled across this feature and was hoping to use it for sharing photos with family members to specific photos to download that I don't want to create user accounts for.

@silverwolf04 commented on GitHub (Jul 7, 2025): Getting this refactored to be more secure would be great. I had stumbled across this feature and was hoping to use it for sharing photos with family members to specific photos to download that I don't want to create user accounts for.

backuprepo referenced this issue

2025-12-22 07:59:04 +01:00

[PR #5360] [CLOSED] Rename Emby.Drawing and fix Skia warnings #10317

backuprepo referenced this issue

2025-12-22 07:59:12 +01:00

[PR #5366] [MERGED] Reduce Skia conversions #10321

backuprepo referenced this issue

2025-12-22 08:56:14 +01:00

[PR #9054] [MERGED] Rename Emby.Drawing and move to src #11774