Claude
e781557694
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>
6 lines
423 B
JavaScript
6 lines
423 B
JavaScript
/// Pretty URL for the account settings editor: /settings → the static page.
|
|
/// The page itself (pb_public/settings.html) is a login → decrypt → edit →
|
|
/// re-encrypt flow for the client-encrypted addon_config; everything happens in
|
|
/// the browser against the normal collection API, so there's no server logic
|
|
/// here beyond this redirect.
|
|
routerAdd("GET", "/settings", (e) => e.redirect(302, "/settings.html"))
|