You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
56 lines
2.6 KiB
Markdown
56 lines
2.6 KiB
Markdown
+++
|
|
title = "[TRIAGE] Auth code storage strategy — localStorage persistence vs component-only state?"
|
|
priority = 7
|
|
status = "done"
|
|
ticket_type = "task"
|
|
dependencies = []
|
|
+++
|
|
|
|
<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>
|