91 lines
7.6 KiB
Markdown
91 lines
7.6 KiB
Markdown
# Handoff — verifiche estese ThothII / Omics
|
||
|
||
Aggiornato il 27 settembre 2026. L’utente ha chiesto di affidare a un’attività
|
||
successiva le verifiche residue e di pubblicare la documentazione del rilascio.
|
||
**Aggiornamento e collaudo funzionale conclusi con successo; matrice estesa aperta.**
|
||
Questo documento è il punto di ripresa per le sole prove ancora da registrare.
|
||
|
||
## Stato acquisito e confini
|
||
|
||
Leggere [PROJECT_STATE.md](../../PROJECT_STATE.md), il
|
||
[report del rilascio](2026-09-26-server-release-execution.md), la
|
||
[matrice di accettazione](../testing/authentication-manual-acceptance.md) e il
|
||
[contratto upstream](../install/authentication-upstream.md).
|
||
|
||
Il 26 settembre sono stati distribuiti ThothII `497ab840` e il fix proxy Omics
|
||
`928f7e9f`, conservando l’immagine web Omics. Backup verificato e rollback sono
|
||
registrati nel report. L’utente ha confermato accesso senza secondo login,
|
||
controlli IT/EN, tema, fullscreen/Esc e avvio → interruzione → ripresa di una
|
||
sessione. Le prove automatiche di health, proxy anonimo/header falsificati,
|
||
asset, TLS locale e preservazione dati/configurazioni sono passate.
|
||
|
||
Queste sono evidenze del rilascio, non una nuova attestazione dello stato live.
|
||
Non ripetere backup/deploy né attivare maintenance per questo collaudo. Usare
|
||
account autorizzati e sessioni fittizie; DWH read-only. Non modificare ruoli,
|
||
Authentik, credenziali, modelli, archivi o configurazioni per far passare una prova.
|
||
Un problema che richieda un nuovo rilascio va prima diagnosticato e pianificato.
|
||
|
||
## Prima azione alla ripresa
|
||
|
||
1. Rileggere le conferme nel report: non chiedere all’utente di ripetere il ciclo
|
||
funzionale già riuscito, salvo regressioni o cambio di versione.
|
||
2. Verificare in sola lettura revisioni/container e stato dell’installazione.
|
||
Distinguere eventuale drift dalla baseline pubblicata; preservare il lavoro
|
||
e le sessioni in corso. Il `check` dello script di rilascio si aspetta lo stato
|
||
**precedente** al deploy: non usarlo come controllo corrente.
|
||
3. Concordare con l’operatore browser e account già disponibili: autorizzato,
|
||
normale, amministratore e, se disponibile, senza capability Datamart Builder.
|
||
Accedere dal normale login Omics; non chiedere password/cookie/token in chat.
|
||
Se manca un profilo, registrare quel caso come non eseguito senza crearne uno.
|
||
|
||
**Completato quando:** sono registrati data, revisioni effettive, modalità
|
||
embedded/upstream, browser e disponibilità dei profili, senza dati personali.
|
||
L’agente può proseguire con le letture tecniche mentre attende l’operatore.
|
||
|
||
## Prove residue
|
||
|
||
Tutti i casi sotto partono da **non eseguito**. La colonna “chi” indica chi compie
|
||
la parte principale; l’agente prepara i controlli tecnici e registra i risultati.
|
||
|
||
| ID | Chi | Azione concreta | Risultato necessario |
|
||
| --- | --- | --- | --- |
|
||
| V1 — lingua persistita | Operatore + agente | Creare una sessione fittizia con UI italiana, annotarne `interaction_language` tramite il normale stato sessione, interromperla, cambiare UI in inglese e riprendere **la stessa** sessione. | UI inglese, lingua della sessione ancora italiana; domande/scelte nella lingua persistita, SQL e contenuti authored invariati. La ripresa generica già provata non chiude questo caso. |
|
||
| V2 — identità e ruoli | Operatore + agente | Aprire `/datamart-builder/api/me` dalla sessione Omics autenticata; confrontare profilo normale e admin con le capability attese. Provare una richiesta amministrativa di sola lettura con il profilo normale. Se disponibile, provare pagina/API con un account senza capability. | Issuer `portal`, subject Django stabile, ruoli coerenti, `session` e `csrfToken` null. Profilo normale senza accesso amministrativo anche lato server; account senza capability rifiutato. Registrare solo esiti e codici, non identità o payload completi. |
|
||
| V3 — logout e riconnessione | Operatore | Aprire due schede Omics/Datamart Builder con una sessione fittizia; fare logout in una, tornare nell’altra e provocare un ricontrollo con reload/riconnessione. Rientrare attraverso Omics. | La nuova richiesta `/me` e le nuove aperture SSE non riusano l’accesso scaduto; UI protetta rimossa al ricontrollo. Non richiedere la chiusura istantanea di uno stream già aperto: non è il contratto. |
|
||
| V4 — origine delle scritture | Agente, con login dell’operatore | Preparare una coppia di richieste autenticate equivalenti su una risorsa fittizia autorizzata: prima same-origin, poi con origine estranea, attraversando il proxy pubblico. Confrontare lo stato della risorsa prima/dopo. Usare un harness HTTP locale con credenziali solo in memoria o file protetto; non affidarsi a `fetch` per impostare manualmente `Origin`. | La scrittura same-origin riesce e quella cross-origin è negata senza mutazioni. Dimostrare che la seconda richiesta è autenticata: un 403 dovuto alla sola assenza di cookie non prova la difesa Origin. I test isolati già verdi sono evidenza complementare, non sostituiscono questo caso. |
|
||
| V5 — lettura amministrazione | Operatore autorizzato | Aprire Database, Memory ed Evidence e controllare disponibilità dei dati preesistenti, selezione, pannelli e scroll. | Viste leggibili, nessun errore e nessuna scrittura/sincronizzazione necessaria per aprirle. Annotare quale area è stata verificata senza copiare contenuti clinici. |
|
||
| V6 — reload e preferenze | Operatore | Con sessione selezionata e Pi fermo, scegliere lingua e tema dal portale e ricaricare. | Preferenze e selezione coerenti; i documenti si riaprono senza avviare automaticamente Pi o una nuova generazione. La lingua persistita della sessione resta quella originale. |
|
||
| V7 — HTTPS esterno | Operatore | Confermare se le prove precedenti sono state svolte da una postazione esterna al server. Se non attestato, aprire il portale dal client abituale attraverso il nome pubblico e verificare config, asset e connessione eventi. | Accesso HTTPS senza avvisi di certificato, mixed content o errori di rete. Annotare browser e tipo di accesso, senza IP personali. Il curl locale con CA e risoluzione a 127.0.0.1 non chiude questo caso. |
|
||
|
||
Per V4 preparare e rendere verificabile il probe prima di eseguirlo: deve agire
|
||
solo sulla risorsa di prova concordata e controllare l’assenza di mutazioni nel
|
||
caso negato. In assenza di credenziali utilizzabili localmente, lasciare il caso
|
||
non eseguito; non estrarre sessioni di altri utenti o cambiare le regole Origin.
|
||
I comandi e gli endpoint concreti vanno derivati dalla versione effettivamente
|
||
installata, non inventati a partire da questo elenco.
|
||
|
||
## Registrazione e criterio di chiusura
|
||
|
||
Aggiornare questa tabella dopo ogni prova, collegando evidenze redatte o una
|
||
conferma esplicita dell’operatore. Un caso parziale resta aperto per i profili o
|
||
scenari mancanti. In caso di difetto, annotare riproduzione, atteso/ottenuto e
|
||
revisione; correggere e riprovare il caso interessato prima di dichiararlo superato.
|
||
|
||
| Caso | Stato iniziale | Data / versione / evidenza |
|
||
| --- | --- | --- |
|
||
| V1 | Non eseguito | — |
|
||
| V2 | Non eseguito | — |
|
||
| V3 | Non eseguito | — |
|
||
| V4 | Non eseguito | — |
|
||
| V5 | Non eseguito | — |
|
||
| V6 | Non eseguito | — |
|
||
| V7 | Non eseguito | — |
|
||
|
||
**Chiusura delle verifiche residue:** ogni caso V1–V7 ha esito e prova registrati;
|
||
per dichiarare la matrice estesa superata devono essere tutti verdi. Un rinvio
|
||
esplicito o un prerequisito mancante va riportato come tale, non come successo.
|
||
Aggiornare quindi report di rilascio, questo handoff e PROJECT_STATE.md.
|
||
|
||
L’aggiornamento applicativo e il collaudo funzionale già confermati restano conclusi;
|
||
questo follow-up non richiede di reinstallare né di ripetere il rilascio.
|