2.6 KiB
+++ title = "[TRIAGE] Auth code storage strategy — localStorage persistence vs component-only state?" priority = 7 status = "done" ticket_type = "task" dependencies = [] +++
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_valueprop; constraints updated with resolved storage approach. - c3503b (UI sub-project): 0bc655 removed, 5379eb added.