write down the plugin route authorization design, agreed and deferred
A plugin's settings routes should be owner-only while the plugin itself stays grantable — jellyfin's /_config holds a server's admin token and drives provisioning, and a Member granted the plugin can reach it today. Agreed: the platform says who is asking, the plugin decides what that means inside its own surface. That is not new — manifest.ts already refuses an ownerOnly permission on the grounds that finer visibility is the plugin's business. Two refinements recorded rather than assumed. Pass isOwner and the effective level, never the role name: roles are the platform's vocabulary and a plugin branching on "Super Admin" gives every plugin repository an opinion about it, so renaming a role would change authorization in code the platform does not own. And nothing may be trusted from the caller — the proxy's three-item header allowlist is what makes X-Officer-User safe, and a new header inherits that only while it stays an allowlist. One disagreement, recorded as a proposal rather than settled: pure plugin-side enforcement is the shape assertPermissionTotality exists to prevent. Jellyfin will check because we are about to write the check; the next plugin's author forgets a route and nothing notices. So: declare owner-only path prefixes in the manifest, enforce them in the proxy, and pass the facts to the sidecar as well. The real prerequisite is not the guard. Connections are per-user, so locking /_config leaves a Member with a plugin that can only show them a connect form they are forbidden to submit. The fix that fits what exists is the owner's server URL with the member's own token from jellyfin_accounts — which is arguably why provisioning mints those tokens. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -14,6 +14,14 @@ the owner's OS user and can never be granted. Indirection there really is accide
|
||||
|
||||
## Multi-user
|
||||
|
||||
- [ ] **A plugin's settings routes are reachable by anyone the plugin is granted to.** Jellyfin's
|
||||
`/_config` stores a server's admin token and drives provisioning, and a Member granted the plugin
|
||||
can reach it. Agreed 2026-08-21 that the plugin should enforce this from facts the platform passes
|
||||
(`isOwner` plus the effective level, never the role name), with a proposal to declare owner-only
|
||||
path prefixes in the manifest so forgetting the check is not a silent hole. **Blocked on credential
|
||||
resolution:** connections are per-user, so locking `/_config` today leaves a Member with a plugin
|
||||
that only shows a connect form they may not submit. See `docs/plugin-route-authorization.md`.
|
||||
|
||||
- [ ] **`deprovisionOsAccount` is written but has never run against a real account.** Landed 2026-08-12 in
|
||||
`os-user-deprovision.ts` and wired into `deleteUserHandler`, which now refuses to delete the row when
|
||||
the Linux teardown fails — so a failure is retryable instead of forgotten. Only the pure guards
|
||||
|
||||
Reference in New Issue
Block a user