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:
@@ -438,6 +438,10 @@ explaining why it was safe.
|
||||
mounted and what it knows, the URL-vs-channel split for panel-to-panel communication, and the
|
||||
persistence key families. Read before building a panel app. Its defect list is
|
||||
`docs/workspace-panel-todo.md`.
|
||||
- `docs/plugin-route-authorization.md` — **design, not built**: making a plugin's settings routes
|
||||
owner-only while the plugin itself stays grantable. What the proxy should pass (`isOwner` and a level,
|
||||
never the role name), why declaring owner-only paths in the manifest beats trusting every plugin to
|
||||
remember, and the credential-resolution work that has to land first
|
||||
- `docs/secret-store.md` — **design, not built**: moving the encryption and signing keys out of `.env`
|
||||
into a SQLite store, why they cannot live in Postgres, and key rotation. Also records the core/plugin
|
||||
split it assumes — light plus `officer-headscale` is the core; Vaultwarden and the wallet are plugins
|
||||
|
||||
Reference in New Issue
Block a user