vibed/quotesdb/.beans/quotesdb-9e3j--triage-auth-code-storage-strategy-localstorage-per.md

title	status	type	priority	created_at	updated_at
[TRIAGE] Auth code storage strategy — localStorage persistence vs component-only state?	completed	task	high	2026-03-10T23:32:05Z	2026-03-10T23:32:05Z

This is a triage decision ticket. It must be resolved before dependent implementation tickets can proceed. Auth code storage strategy for the UI: should the auth code be stored in localStorage (persisted across sessions) or kept only in component state (lost on page reload)? 1. **Component state only** — auth code is lost on page reload. User must re-enter it each time. Simpler and more secure. 2. **localStorage per quote ID** — store `auth_code_{id}` in localStorage so the user doesn't need to re-enter it for quotes they created. Risk: plaintext in localStorage. 3. **Session storage** — same as localStorage but cleared when the tab closes. Middle ground. **Chosen approach: Option 3 — session storage per quote ID.**

The auth code is stored in sessionStorage under the key auth_code_{quote_id}. It is automatically cleared when the browser tab closes. No manual clear-on-delete is strictly required, but is implemented as good practice (after a successful DELETE, the code is no longer useful and should not linger).

Why not localStorage (option 2): the app explicitly tells users to store their auth code externally ("Store this — it cannot be recovered later"). localStorage is indefinite and has a wider XSS exposure window; session storage provides the same in-session convenience without the long-term risk.

Why not component state (option 1): the code would be lost on every page navigation or reload, making the edit/delete flow frustrating in practice.

Session storage covers the primary use case — "I just created this quote and want to edit it" — without adding unnecessary persistence complexity.

Implementation ticket: 5379eb — creates src/bin/ui/storage.rs with get_auth_code, set_auth_code, clear_auth_code utilities wrapping web_sys::window().session_storage(), plus the initial_value: Option<String> prop addition to AuthModal and the parent-component integration pattern (read on modal open, write on success, clear on 403 or DELETE).

Tickets updated:

• f850c6 (AuthModal): triage dependency replaced with 5379eb; goal updated with initial_value prop; constraints updated with resolved storage approach.
• c3503b (UI sub-project): 0bc655 removed, 5379eb added.

`chore(quotesdb): resolve triage — auth-code-storage-strategy-localstorage-persistence-vs-compo`