cap how many people can watch one multi-use link at once
New setting, ten by default, zero for no limit. Single-use links are unaffected, they are one viewer by definition. The catch is what happens at the ceiling. Jellyfin throws SecurityException once a user is at MaxActiveSessions, and that was landing in the generic handler, which marks the record failed and runs cleanup, which deletes the guest account. So without care, adding a ceiling would mean the eleventh person to open a link kicks out the ten already watching and destroys the link. Capacity is caught separately now: the record goes back to the state it was in, nothing is torn down, and the new arrival gets a 503 page inviting them to try again. Worth being honest that this caps how many people can start watching at once, not how many ever get in: each redemption issues its own session token that keeps working until the link is revoked or expires. Revoke is still the hard stop. README picks up the multi-use option, the new setting, and a section on what a multi-use link does and does not protect, plus the known limits around the token in the query string, the unthrottled redeem endpoint, and the tag being hidden in the web UI only.
Cette révision appartient à :
@@ -187,9 +187,9 @@ public sealed class JellyfinGuestUserService
|
||||
EnabledFolders = Array.Empty<Guid>(),
|
||||
EnablePublicSharing = false,
|
||||
LoginAttemptsBeforeLockout = -1,
|
||||
// One viewer for a one-use link. A multi-use link needs a session per
|
||||
// viewer, and 0 is how Jellyfin spells "no limit" in its session check.
|
||||
MaxActiveSessions = record.OneUse ? 1 : 0,
|
||||
// One viewer for a one-use link. A multi-use link gets the configured
|
||||
// ceiling, where 0 is how Jellyfin spells "no limit" in its session check.
|
||||
MaxActiveSessions = record.OneUse ? 1 : Math.Max(config.MaxConcurrentViewers, 0),
|
||||
BlockUnratedItems = Array.Empty<UnratedItem>()
|
||||
};
|
||||
|
||||
|
||||
Référencer dans un nouveau ticket
Bloquer un utilisateur