26 lines
1.4 KiB
Markdown
26 lines
1.4 KiB
Markdown
# User-owned session storage design
|
|
|
|
## Decisioni vincolanti
|
|
|
|
- In server mode ThothII usa PostgreSQL diretto, nello schema Supabase privato
|
|
`thoth_sessions`; il browser non accede mai al database.
|
|
- In local mode ogni utente usa `~/.thothii` (override esplicito `THT_HOME`),
|
|
senza fallback o sincronizzazione con Supabase.
|
|
- Una sessione appartiene al principal `(issuer, subject)`. Nel portale il
|
|
subject è il PK Django; email e username non sono identificatori.
|
|
- Il proxy valida la sessione del portale e inietta identità normalizzata; il
|
|
backend richiede `AUTH_MODE=upstream` in produzione e non riceve token raw.
|
|
- Gli utenti nel gruppo Authentik `authentik Admins` possono gestire ogni
|
|
sessione. Un accesso non autorizzato restituisce 404.
|
|
- Lo schema contiene principals, principal_preferences, sessions,
|
|
session_artifacts, review_decisions e audit_log. Artefatti correnti e
|
|
decision ledger append-only; niente cronologia di artefatti né contenuto
|
|
nell'audit.
|
|
- La sicurezza server combina RLS forzata, un runtime role senza BYPASSRLS,
|
|
contesto attore transaction-local e filtri applicativi espliciti.
|
|
- Non vengono creati embeddings o vector columns per le sessioni. La memoria
|
|
solved_question esistente resta un flusso separato best-effort.
|
|
- Sessioni e preferenze server sono persistite solo nel DB; guasti DB sono
|
|
fail-closed (503). I file temporanei di export sono effimeri.
|
|
- Chat e SSE restano memoria runtime, non artefatti persistiti.
|