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

<context>
This is a triage decision ticket. It must be resolved before dependent implementation tickets can proceed.
</context>

<question>
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)?
</question>

<options>
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.
</options>

<resolution>
**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.
</resolution>

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