31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# Client boundary
|
|
|
|
The Linux client is a Svelte/Tauri control surface for `trixie-server`. It
|
|
renders server-owned state and sends explicit user actions through the shared
|
|
versioned HTTP/WebSocket boundary.
|
|
|
|
The client never stores Twitch refresh tokens or the administrator password,
|
|
calls Twitch directly, executes plugin code, or treats local UI state as
|
|
authoritative. Local overlay drafts and display preferences are recoverable
|
|
presentation data only; the server remains authoritative for publication,
|
|
authorization, Twitch state, and durable history.
|
|
|
|
# Saved-session recovery
|
|
|
|
Native startup verifies the keyring session before loading authenticated data.
|
|
HTTP 401/403 clears the saved session and requests login. Server failures retain
|
|
the credential and retry immediately, then after 3, 10, 15, and repeatedly 30
|
|
seconds. Manual login and logout cancel pending restoration. Dashboard-loading
|
|
failures do not invalidate a successfully verified session.
|
|
Restored sessions retain the server's mandatory credential-replacement state.
|
|
An omitted replacement flag is treated conservatively as requiring setup rather
|
|
than silently allowing the dashboard to consider setup complete.
|
|
|
|
Run `node --test src/session-recovery.test.js` for response classification and
|
|
retry-schedule coverage. This is not a substitute for native AppImage acceptance.
|
|
|
|
Keyring writes use `keyctl padd` with the session supplied through standard input,
|
|
never process arguments. Helper stdout/stderr are discarded so credential payloads
|
|
cannot enter diagnostics. Native tests cover the argument boundary, stdin delivery,
|
|
and helper failure handling without reading or modifying real keyring entries.
|