The builder image is now multi-arch (linux/amd64 + linux/arm64). Both
variants were tested by running this repo's own CI build steps in each
before being pushed as :latest. Jobs therefore no longer need an amd64
host: runs-on moves to ubuntu-latest, which the amd64 runner (draco-x86)
and the ARM runner (oracle-a1) both carry, so jobs go to whichever is
free instead of queueing behind long jobs on draco.
The Dockerfile header now gives the buildx command for the multi-arch
image, so a rebuild does not silently go back to amd64-only.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A shared account previously inherited its members' library access but
none of their content restrictions, so a child could log into "alice+kid"
with their own password and get around their own rating cap.
The shared account now gets the strictest member's parental rating,
unrated-item block, blocked tags and allowed tags, recomputed at
creation, on membership change and at startup. An admin can raise the
rating cap on a slider between the strictest and the loosest member;
unrated and tag rules stay strictest-wins.
What makes raising the cap safe is the unlock rule: after a member's
password matches, both users' live policies are compared and the login
is refused if the account is looser than the member on any field. So
raising the cap above the child's rating means the child's password no
longer opens the account, while the parent's still does. The same rule
bounds the slider - past the loosest member nobody could unlock the
account - so a chosen cap is clamped back into range whenever applied.
Allowed tags need care: Jellyfin reads an empty list as "no whitelist",
so an empty intersection of members' whitelists is written as a sentinel
tag no item carries. Access schedules and channels are not inherited yet.
The shared account is never an administrator. Groups created at the
login screen always inherit and are restricted before the first session
exists. The dashboard shows each member's cap, who a chosen cap shuts
out, and the restrictions in effect, and gains a per-group edit form for
the sync options.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Synced rows only ever had the Played flag set. Jellyfin computes Next Up
from LastPlayedDate on the member's own row and Continue Watching from
the resume position, so a member watching through the shared account got
the tick on each episode but their Next Up never advanced. Members are
now written the way BaseItem.MarkPlayed/MarkUnplayed write: date and
position included. Rows the old version ticked without a date are
repaired the next time the item syncs.
PlaybackFinished was also treated as an unwatched toggle. Jellyfin raises
it on every stop, not just completion (and on 10.11 PlaybackStart resets
Played to false first), so a stop halfway through on the shared account
cleared members' own watched state whenever Sync unwatched was on.
Playback-derived reasons (PlaybackFinished, PlaybackProgress,
UpdateUserData) now only ever mirror "watched"; TogglePlayed and Import
remain explicit and mirror either way. PlaybackProgress is acted on so
the tick lands as soon as the completion threshold is crossed, including
for clients that never report a stop.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Jellyfin 12 moved to .NET 10 and changed the IUserManager surface the
plugin relies on: Users/UsersIds became GetUsers()/GetUsersIds(),
ChangePassword takes a user id, HasPassword left the provider contract,
and the user cache is gone, so every lookup is a detached copy.
The plugin now multi-targets net9.0 (against 10.11.5) and net10.0
(against 12.0.0). The differences sit behind a JELLYFIN_12 constant in
Compat/UserManagerCompat.cs, whose ChangePasswordAsync also carries the
stored hash back onto the caller's instance: on 12 the UpdateUserAsync
that claims the account would otherwise write the stale null password
back over the one provisioning just set.
Each release ships one package per generation, with the fourth version
segment naming the target (x.y.z.11 and x.y.z.12) so a 12 server picks
the 12 package over the 10.11 one. scripts/package.sh wraps jprm for a
single generation and the workflows call it twice. The builder image
moves to the .NET 10 SDK, which builds both targets; the net9.0 test run
rolls forward onto the .NET 10 runtime.
CA1873 is a .NET 10 analyzer that flags the same log calls CA1848 does;
it is set to Info, as in the upstream Jellyfin 12 tree.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Provisioning assigned AuthenticationProviderId and only then called
IUserManager.ChangePassword. Jellyfin dispatches that call to the provider the
user is currently assigned to, so it reached this plugin's own ChangePassword,
which refuses by design. Creating a group by typing "alice+bob" at the login
screen therefore died with NotSupportedException.
Set the placeholder password first, while the freshly created account is still
on Jellyfin's default provider, then claim it.
The new end-to-end tests wire the real provisioning, group and authentication
services together rather than mocking IProvisioningService, and cover a group
created on demand being unlocked afterwards by either member's password. With
the old ordering restored, six of them fail with the original exception.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Jellyfin's UserManager constructor-injects every IAuthenticationProvider, so
building IUserManager forced SharedAccountAuthenticationProvider to be built
first. That provider eagerly required IGroupService and IDynamicGroupService,
both of which need IUserManager, and the container refused to start the server
with "a circular dependency was detected".
Take the two group services as Lazy<T> and dereference them at authentication
time instead. Nobody can log in before the host is up, so the deferred lookup
is always safe. Microsoft's container has no built-in Lazy<T> support, hence
the explicit factory registrations.
The accompanying test builds the service graph through a stand-in that mimics
UserManager's constructor shape and validates it on build, so a reintroduced
cycle fails in CI rather than at server startup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"jane+john" and "john+jane" name the same group, but they did not behave
that way. Jellyfin only routes a login here when no account matches the
typed name, so logging in with the reversed spelling of an existing group
found nothing and quietly created a second shared account for the same
two people - each with its own watched state.
Group identity is now order-independent:
- Member names are sorted alphabetically when building an account name,
so a given set of members always produces the same name.
- Before creating anything, the login path looks for an existing group
whose members are exactly the named set, compared as a set rather than
a sequence, and logs into that account if it finds one.
- Stored member lists are kept in the same canonical order on create and
update, so a group's stored order does not depend on the order an
admin happened to select members in.
Passing no name through to provisioning lets it generate the canonical
name, rather than preserving whatever order was typed.
Members are also now checked in the order they were typed, stopping at
the first match, so whoever puts their own name first is verified first.
Verification is a deliberately slow hash comparison, so the ordering is
worth having; it is only a preference, and any member's password still
unlocks the group.
Two CI fixes.
The builder image lacked nodejs, so every job died at the first step with
"exec: node: executable file not found in $PATH" (exit 127).
actions/checkout and actions/cache are JavaScript actions: the runner
execs node inside the job container to run them, so the image needs it
even though the build itself does not. Verified by exec'ing node with no
shell, which is how the runner invokes it, and by pulling the pushed
image back from the registry.
TwoExplicitLists_IntersectToTheCommonLibraries compared a sorted actual
against an unsorted hardcoded expected, so it only passed when the
randomly generated library GUIDs happened to sort that way - it failed
about half of all runs and would have made CI intermittently red. The
intersection is a set, so it now asserts on membership and count rather
than ordering. Confirmed with 10 consecutive clean runs, up from ~50%.
The release and nightly workflows stamp a date-based version into
build.yaml (1.0.20260729.42). That build segment exceeds the 16-bit
limit AssemblyVersion and FileVersion require, so it would fail the
compile with CS7034 if it reached them.
Directory.Build.targets is imported after Directory.Build.props and is
not rewritten by CI, so pinning the assembly identity there keeps those
builds working. The manifest version is untouched - Jellyfin identifies
plugins by GUID plus manifest version, not assembly version. Verified by
building with a date-based version injected.
Previously the shared account's libraries were chosen independently of
its members, so a group could see a library that one of its members was
blocked from - joining a group became a way to gain access. That was
especially sharp with auto-created groups, where no admin is in the loop.
A shared account is now granted exactly the libraries every member can
already reach. If one member is blocked from a library, no group
containing them can see it. The account is therefore always a subset of
what each member could reach alone, which is what makes creating groups
at the login screen safe to leave on by default.
Details:
- "Enable all folders" is expanded to concrete library ids before
intersecting, since it cannot otherwise be compared with an explicit
list. Shared accounts are always given an explicit list, never the
all-folders permission, so newly added libraries do not silently widen
an existing group.
- Explicitly blocked folders are subtracted even for members who
otherwise have access to everything.
- Fails closed: an unresolvable member contributes no access rather than
being treated as unrestricted.
- Recomputed when membership changes, and re-applied to every group at
startup so narrowing a member's own access narrows their groups.
Drops the now-meaningless EnableAllFolders/EnabledFolders provisioning
inputs and the DynamicGroupsEnableAllFolders setting. Adds 8 tests
covering the intersection rules.
Replaces the plugin template with a working plugin that lets several
users share one viewing account while keeping their individual watched
lists accurate.
Three pieces:
- Auto-creating groups. Logging in as "alice+bob" with any named
member's own password provisions the shared account and signs you in.
Verified against 10.11.5: AuthenticateUser offers unmatched usernames
to every enabled provider and re-queries afterwards, which is the hook
this relies on. Gated on a real member password so knowing two
usernames is not enough to create an account.
- Multi-password authentication. IRequiresResolvedUser hands us the
resolved shared account; each member's live stored hash is checked via
ICryptoProvider.Verify. Deliberately avoids re-entering
UserManager.AuthenticateUser, which would trip every member's
failed-attempt counter whenever a different member's password matched.
- One-way played-state sync. Shared account to members only, filtered to
PlaybackFinished/TogglePlayed/Import so playback progress ticks are
ignored. No loop guard needed: member writes carry a non-shared id.
Membership is stored as user IDs rather than re-parsed from the username,
so shared accounts can be renamed freely. The +/name collision resolves
itself because Jellyfin only consults the plugin when no local user
matches the typed name.
Targets Jellyfin 10.11.x / net9.0. Adds Gitea CI (test, build, release),
a builder image, and 34 tests covering the auth and sync rules.
The markdown codeblocks in the README were using `json`, which has no support for comments, making them highlighted in red. `jsonc` does have support, correctly rendering the codeblocks.
The ${env:XDG_DATA_HOME} variable is not used, as this variable resolves
to the current working directory within Visual Studio Code's development
container. By manually specifying the file path, it is possible to use
Visual Studio Code's development container.
The "mkdir" command uses the "-p" flag. This flag creates the parent
directories, as well. Should they already exists, the command moves
down to the next folder to create without throwing an error.
The "-r" parameter of the "cp" is required to recursively copy all
files and directories within the "publish" directory.
dtourolleandClaude Opus 5.5