Writing the tag into index.html on disk fails on most fresh installs
(linuxserver image, distro packages, Docker as a normal user) because
the web files belong to root. A middleware now adds the tag to the
response instead, so the ShareLink action and the guest lockdown work
right after install. The on-disk edit stays as a best-effort extra, and
the tag uses a relative src so it also works under a base URL.
Bump to 1.0.8.0.
On linuxserver/jellyfin the web folder belongs to root, so copying
index.html to index.html.sharelinks.bak threw even when index.html itself
was writable, and the ShareLink action never got injected. The backup is
best-effort now.
Bump to 1.0.7.0.
The sign-in page stored the guest's server entry with LastConnectionMode 1
(Remote) but only a ManualAddress. jellyfin-web 12 builds its ApiClient from
that entry, gets no address, throws "Must supply a serverAddress" and never
leaves the splash screen. Store mode 2 (Manual), which is what jellyfin-web
itself writes after a normal sign-in.
Also hide the Modern layout header links, user menu and drawer toggle for
guests (Modern is the default in 12), and close the item action sheet on
desktop when ShareLink opens its popup. Escape only closes it in the TV
layout, a click on the dialog container works everywhere.
Bump to 1.0.6.0.
Jellyfin 10.11.9 changed IUserManager.ChangePassword to take the user id
instead of the User. A call compiled against either signature throws
MissingMethodException on the other, so look up whichever one the server
has and call it through a delegate. Bumps to 1.0.5.0.
Jellyfin does not cascade a user delete to the Device rows redemption
creates, and DeviceManager throws for the whole listing when one device's
user is missing, so a single leftover guest 404s the dashboard devices page.
Deletes the guest's devices before the user, and sweeps devices this plugin
created whose user is already gone at startup for links torn down by older
builds.
* block plugin routes for share guests
Adds a global MVC filter that refuses share-guest accounts on any plugin
controller. Jellyfin's own API stays open, the share tag policy already
bounds it and playback needs it.
Guests are identified by the auth provider marker on the account, so this
covers a leaked token used from curl or a native client, not just the web
client where the CSS lockdown runs.
* add plugin exception list and honest wording
Config page lists installed plugins with a checkbox each, for the ones that
need to answer guests during playback. Default is unticked.
Renames the hidden selectors setting to say it is cosmetic, and stops the
readme implying the web client lockdown confines anything.
* bump to 1.0.4.0
Sharing one season let the guest see every season of that show. Sharing a whole
series or a single episode was fine, which is what made it look like a season
specific problem.
The cause is that the tag went upwards as well as downwards. BuildTagTreeTargets
added a season's parent series, so the guest's tag landed on the series itself,
and Jellyfin's GetInheritedTags is an item's own tags plus every ancestor's, with
AllowedTags matched against that. Tagging the series therefore made every other
season and episode under it inherit the tag and become visible. Sharing a series
looked correct because the whole show is meant to be visible, and sharing an
episode looked correct because nothing above it was ever tagged.
Tagging now only ever goes down: the shared item, and its descendants when it is a
folder. A guest sent one season gets that season and its episodes, and the series
page is not theirs to open, which is what sharing a season should mean.
Removal deliberately still reaches up to the parent series. Links created by
earlier builds put the tag there, and taking a tag off can only remove access, so
those get cleaned up when the link expires or is revoked instead of being stranded
on the series forever.
The dashboard listed every share ever made, including ones revoked or expired
months ago, and nothing ever pruned them. There is now a "Clean up finished links"
button next to Refresh that runs a normal cleanup pass and then drops the records
that are done with, reporting how many went.
Only revoked, expired and failed records are removed. A link that can still be
used is left alone, including a spent one-use link whose guest is still watching
until it expires, since that record is Redeemed rather than finished.
Folded into 1.0.3.0 rather than shipped as 1.0.3.1: the ceiling fix and this are
going out as one replacement of that version.
The ceiling shipped in 1.0.3.0 did the opposite of its job. Jellyfin throws
MediaBrowser.Controller.Net.SecurityException when a user is at their session
limit, and the catch that was meant to handle it named System.Security's type of
the same name, so it never matched. The exception fell through to the failure
path, which marks the record failed and runs cleanup, which deletes the guest
account. Live result with the ceiling at 3: the fourth viewer got a dead-link
page, the three already watching were kicked out, and the link was gone.
Rather than swap one exception type for another and trust it, the over-the-ceiling
viewer is now turned away before anything is written at all: no tag work, no
status change, the guest account untouched. The check mirrors what Jellyfin does
when it creates a session, counting sessions for the guest against the ceiling.
The typed catch stays as a backstop for the race between the check and the call,
and it now names the right type.
A link that has never been redeemed has no guest yet, so it can never be at a
ceiling, and 0 still means no limit.
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.
The create popup now has a "Let several people use this link" box next to the
expiry controls. Tick it and the link stays redeemable by everyone you send it to
until it expires; leave it and you get the old behaviour, where the first person
to open it is the only one who gets in. The plugin setting that used to be the
only control is now just what the box starts out as, and its label on the config
page says so, because "Default one-use links" explained nothing.
Multi-use did not actually work before this. Two things in Jellyfin stopped it,
and both had to change:
Guests were given MaxActiveSessions = 1, and AuthenticateNewSessionInternal throws
SecurityException once a user is at that limit. The second viewer's redemption
would fail, the record would go to Failed, and cleanup would then delete the guest
account, kicking the first viewer out too. Multi-use links now get 0, which is how
Jellyfin spells "no limit" in that check.
The device id was generated once and reused for every redemption, and
GetAuthorizationToken logs out every existing session for the same user and device
before issuing a token. So even under a raised session cap, each new viewer would
have revoked the previous one's token. Multi-use links now mint a device id per
redemption.
Both viewers of a multi-use link share one temporary account, so they also share
playback position and watched state on the shared title.
The check skipped hiding when the Users/Me lookup came back empty, which is the
one case where we do not know who is looking. Only a positive administrator
verdict skips it now.
jimmyGALLAND
Francois CB
Franciskid