richiexec/amber-backend
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add /settings web editor for the encrypted addon config #9

Merged
richiexec merged 1 commit from feature/web-settings-editor into main 2026-07-23 16:21:15 +00:00
Conversation 0 Commits 1 Files changed 2 +321
richiexec commented 2026-07-23 16:20:48 +00:00
Owner
Copy link

Why

A place to change a family member's account settings (addon URLs + TMDB key) from any browser instead of typing them on a TV — the ask being "manage my parents' settings without their Windows PC having the app installed." It also doubles as the per-user config-update tool: the onboarding template is a one-time seed, so this is how you edit a live account's config.

How

pb_public/settings.html — a login → decrypt → edit → re-encrypt flow, all client-side against the existing collection API (no new server logic):

  1. auth-with-password → token + user record (nsfwEnabled); the password is kept only in-memory.
  2. Load the owner's addon_config (collection rules already scope to profile.user).
  3. Decrypt the blob in-browser with the password (PBKDF2-HMAC-SHA256 → AES-256-GCM, byte-identical to the app's addon_config_crypto.dart and the onboarding page).
  4. Edit addon URLs / TMDB key, then re-encrypt and PATCH.

Two design points that matter

  • Re-encrypt reusing the record's existing salt. The vault key is PBKDF2(password, salt); an already-logged-in device caches that key and has no password on a restored session. Reusing the salt keeps the key identical, so the edited blob decrypts on the TV with no re-entry. Minting a fresh salt (like signup does) would make the TV unable to decrypt and nag the user to re-enter addons on the TV — the exact thing we're avoiding.
  • 18+ fields gated on nsfwEnabled. The adult addon URL + enable toggle render only for an 18+ account; a clean account never sees them, and their stored values are carried through untouched on save (mirrors the app's non-adult-device behavior).

pb_hooks/settings.pb.js — a /settings → /settings.html redirect for a clean URL.

Testing

  • Crypto round-trip, salt-reuse (device keeps decrypting), wrong-password rejection, and "different salt can't decrypt" (confirming the reuse requirement) all verified against the app's exact format via WebCrypto in Node.
  • Login screen renders correctly (matches the onboarding page style).
  • Full E2E pends deploy (needs the live PocketBase): after redeploy I'll drive /settings with the test account — log in, edit, save, and confirm the app picks up the change.

🤖 Generated with Claude Code

## Why A place to change a family member's account settings (addon URLs + TMDB key) from any browser instead of typing them on a TV — the ask being "manage my parents' settings without their Windows PC having the app installed." It also doubles as the **per-user config-update tool**: the onboarding template is a one-time seed, so this is how you edit a *live* account's config. ## How `pb_public/settings.html` — a login → decrypt → edit → re-encrypt flow, all client-side against the existing collection API (no new server logic): 1. `auth-with-password` → token + user record (`nsfwEnabled`); the password is kept only in-memory. 2. Load the owner's `addon_config` (collection rules already scope to `profile.user`). 3. **Decrypt the blob in-browser** with the password (PBKDF2-HMAC-SHA256 → AES-256-GCM, byte-identical to the app's `addon_config_crypto.dart` and the onboarding page). 4. Edit addon URLs / TMDB key, then re-encrypt and PATCH. ### Two design points that matter - **Re-encrypt reusing the record's existing salt.** The vault key is `PBKDF2(password, salt)`; an already-logged-in device caches that key and has no password on a restored session. Reusing the salt keeps the key identical, so the edited blob decrypts on the TV **with no re-entry**. Minting a fresh salt (like signup does) would make the TV unable to decrypt and nag the user to re-enter addons on the TV — the exact thing we're avoiding. - **18+ fields gated on `nsfwEnabled`.** The adult addon URL + enable toggle render only for an 18+ account; a clean account never sees them, and their stored values are carried through untouched on save (mirrors the app's non-adult-device behavior). `pb_hooks/settings.pb.js` — a `/settings` → `/settings.html` redirect for a clean URL. ## Testing - Crypto round-trip, salt-reuse (device keeps decrypting), wrong-password rejection, and "different salt can't decrypt" (confirming the reuse requirement) all verified against the app's exact format via WebCrypto in Node. - Login screen renders correctly (matches the onboarding page style). - **Full E2E pends deploy** (needs the live PocketBase): after redeploy I'll drive `/settings` with the test account — log in, edit, save, and confirm the app picks up the change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
richiexec added 1 commit 2026-07-23 16:20:49 +00:00 
A login → decrypt → edit → re-encrypt page so account settings (the
addon URLs + TMDB key) can be changed from any browser instead of typing
them on a TV. Doubles as the per-user config-update tool (editing a live
account's config, which the one-time onboarding template can't do).

- pb_public/settings.html: auth-with-password, load the owner's
  addon_config (rules already scope to profile.user), decrypt the blob
  in-browser with the password (PBKDF2→AES-GCM, byte-identical to the app
  + onboarding page), edit fields, re-encrypt and PATCH.
- Crucial: re-encrypt reusing the record's EXISTING salt, so the derived
  key is unchanged and an already-logged-in device (which cached that key
  and has no password on a restored session) decrypts the edited blob
  with no re-entry. A fresh salt would force a TV re-entry — the opposite
  of the point.
- 18+ fields (adult addon URL + enable toggle) render only for an account
  with nsfwEnabled; a clean account never sees them and their stored
  values are carried through untouched on save.
- pb_hooks/settings.pb.js: /settings → /settings.html redirect.

No server logic beyond the redirect — all crypto/IO is client-side against
the existing collection API. Crypto round-trip + salt-reuse + wrong-key
rejection verified against the app's format (WebCrypto, Node).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
richiexec merged commit a98f52e3bc into main 2026-07-23 16:21:15 +00:00
richiexec deleted branch feature/web-settings-editor 2026-07-23 16:21:16 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: richiexec/amber-backend#9
No description provided.
Delete branch "feature/web-settings-editor"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?