6da194045b
Vellum now speaks two foreign protocols, so the clients people already own can
use it. Both are translation layers over queries that already exist, and both go
through the same grant chokepoint as the web app — a token is a second way to be
a user, never a second set of permissions.
Shared foundation (coordinator, written before dispatch)
- migrations/0012_api_tokens.sql + internal/apitoken. Both protocols need a
credential that is not the session cookie, and letting two agents each invent
a token table would have produced two incompatible ones.
- The table stores two shapes for a real reason: a Jellyfin token is a bearer
value so only its hash is kept, while a Subsonic key must be recoverable
because verifying `t` means computing md5(key + salt) server-side. token_plain
is therefore the one column in the schema holding a usable credential. It is a
generated random secret, never a user password, and it is revocable.
Wave 9 - Jellyfin
- /System/Info/Public, /Users/AuthenticateByName, /Users/Me, /Users/{id},
/Items, /Users/{id}/Items, /Items/{id}, /Items/{id}/Images/Primary,
/Items/{id}/PlaybackInfo, /Videos/{id}/stream, /Audio/{id}/stream,
/Sessions/Playing{,/Progress,/Stopped}.
- Auth accepts X-Emby-Token, X-MediaBrowser-Token, ?api_key=, and
Authorization: MediaBrowser Token="...". The ?api_key= form is the one that
matters: <video> elements cannot set headers.
- Honest about the one thing Vellum cannot do. PlaybackInfo reports
SupportsDirectPlay/SupportsDirectStream true and SupportsTranscoding FALSE,
with a DirectStreamUrl carrying the api_key. A client that disables both
direct modes is demanding a transcode and is refused with ErrorCode
"NoCompatibleStream" — rather than handed a TranscodingUrl that would never
resolve, which is how a client hangs forever.
Wave 10 - Subsonic
- /rest/{method} dispatch with ping, getLicense, getMusicFolders, getIndexes,
getArtists/getArtist/getAlbum, getMusicDirectory, getSong, search3, stream,
getCoverArt, getAlbumList2, getRandomSongs, scrobble, getUser, getPlaylists,
plus GET /api/v1/subsonic/credentials to hand a user their key.
- Auth via t=md5(key+salt), p=key, constant-time comparison. A bad credential
returns HTTP 200 with the envelope status "failed" and error code 40 — NOT an
HTTP 401. Subsonic clients read the envelope, and getting this wrong is the
single most common integration failure in that protocol.
- stream supports format=raw and never invokes ffmpeg.
Coordinator wired both into main.go (the line agents were told to leave alone)
and verified against real requests.
Verified end to end, 18 packages pass, gofmt/vet clean, svelte-check 0/0:
- Jellyfin: discovery, AuthenticateByName minting a token, /Items reporting 18,
PlaybackInfo showing SupportsTranscoding=false, and a Range request to
/Videos/{id}/stream using ONLY ?api_key= returning 206 with Content-Range.
- Subsonic: ping as JSON and XML, md5(key+salt) auth succeeding, and a bad token
returning the failed envelope with code 40.
- Scoping, both protocols, with a genuinely non-admin user: 0 items, 404 on an
admin-only item, 404 on its stream, 0 music folders; admin still sees 18.
- The SPA is not shadowed by the root-mounted compat paths: /, /healthz and
/api/v1/version all still answer correctly.
Both agents failed with an HTTP 400 at the REPORT stage, not during the work;
their files were complete and compile, so the work was salvaged and verified
here rather than redone.
34 lines
1.8 KiB
SQL
34 lines
1.8 KiB
SQL
-- 0012_api_tokens.sql — tokens for non-browser clients.
|
|
--
|
|
-- Jellyfin clients send `X-Emby-Token`, Subsonic clients send `t=`, and neither
|
|
-- speaks the session cookie the web app uses. Rather than weaken the cookie
|
|
-- model, these live beside it: a token is a second, revocable way to be a user,
|
|
-- and every request still resolves to the same auth.User and goes through the
|
|
-- same grant chokepoint.
|
|
--
|
|
-- Two storage shapes, for a real reason:
|
|
--
|
|
-- * Jellyfin sends the token as a bearer value, so only a hash is needed —
|
|
-- same reasoning as sessions. A stolen database yields no usable token.
|
|
-- * Subsonic's `t` parameter is md5(apiKey + salt), and the server must
|
|
-- compute that to compare. That requires the KEY itself, so a Subsonic key
|
|
-- is stored in the clear. It is a generated random secret, never a user's
|
|
-- password, and it is revocable — but it is worth being explicit that this
|
|
-- column is the one place a usable credential sits in the database.
|
|
--
|
|
-- `token_plain` is therefore empty for Jellyfin and populated for Subsonic.
|
|
|
|
CREATE TABLE api_tokens (
|
|
id INTEGER PRIMARY KEY,
|
|
user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
|
|
kind TEXT NOT NULL, -- 'jellyfin' | 'subsonic'
|
|
label TEXT NOT NULL DEFAULT '', -- shown in the UI, e.g. "Living room TV"
|
|
token_hash TEXT NOT NULL, -- sha256 hex, used for lookup
|
|
token_plain TEXT NOT NULL DEFAULT '', -- Subsonic only; see above
|
|
created_at TEXT NOT NULL DEFAULT '',
|
|
last_used_at TEXT NOT NULL DEFAULT '',
|
|
expires_at TEXT NOT NULL DEFAULT '' -- '' means never
|
|
);
|
|
|
|
CREATE INDEX idx_api_tokens_hash ON api_tokens(token_hash);
|
|
CREATE INDEX idx_api_tokens_user ON api_tokens(user_id, kind);
|