5.7 KiB
Progetto B PSD — collaudo manuale Authentik e Aritmolab
Questo documento verifica il percorso finale di produzione. Si esegue soltanto dopo il PASS del Progetto A e dopo che Sol ha completato i preflight Authentik, Supabase, Nginx e bilanciatore.
Regole
- Usare identità di prova approvate: una ordinaria, una amministrativa e, se disponibile, una senza gruppi ThothII.
- Non acquisire token, cookie, password, chiavi private, claim completi o trace browser contenenti URL di callback con parametri.
- Partire dalla home reale di Aritmolab, non da un URL interno di ThothII.
- Segnare
PASS,FAILoPENDING; non dedurre il PASS da test automatici.
Dati iniziali
| Campo | Valore redatto |
|---|---|
| Data/ora UTC | |
| SHA ThothII/workspace | |
| Origine pubblica | |
| SHA/revisione Aritmolab | |
| Nome/ID applicazione Authentik | non inserire secret |
| Database Supabase | |
| Schema sessioni | thoth_sessions |
| Operatore/revisore |
1. TLS, routing e pagina iniziale
| Prova | Azione | Risultato atteso | Esito | Note |
|---|---|---|---|---|
| HTTP | aprire origine in HTTP | redirect a HTTPS | ||
| Certificato | ispezionare il lucchetto/catena | hostname corretto, nessun warning | ||
| Home Aritmolab | aprire URL ufficiale | pagina disponibile | ||
| Sidebar | individuare ThothII | link presente come prima | ||
| Destinazione | aprire il link | nuovo frontend ThothII | ||
| API | caricare l’app | nessun 502/404 o mixed content | ||
| SSE | avviare attività modello | aggiornamenti continui, niente buffering evidente |
2. Single sign-on
Chiudere ogni precedente sessione di test secondo la procedura concordata. Accedere ad Aritmolab con l’identità ordinaria, quindi aprire ThothII dalla sidebar.
| Prova | Risultato atteso | Esito | Note |
|---|---|---|---|
| Primo login | Authentik autentica l’utente | ||
| Passaggio sidebar | nessuna seconda richiesta di credenziali | ||
| Callback | ritorno all’origine pubblica ThothII | ||
| Identità | nome visualizzato coerente, senza dati grezzi del token | ||
| Browser storage | nessun access/id token in Local/Session Storage | ||
| Cookie | cookie ThothII HttpOnly/Secure/SameSite secondo configurazione |
Non copiare il valore del cookie nel rapporto.
3. Ruoli e autorizzazione
| Identità/caso | Risultato atteso | Esito | Note |
|---|---|---|---|
| Gruppo utente | può creare, leggere e gestire le proprie sessioni | ||
| Gruppo utente | Pi Management e funzioni admin negate con 403/non visibili | ||
| Gruppo admin | funzioni amministrative documentate disponibili | ||
| Nessun gruppo mappato | autenticato ma operazioni protette negate | ||
| Gruppo estraneo aggiuntivo | nessun cambiamento e nessun warning | ||
| Header identità forgiato | nessun privilegio aggiuntivo |
Le prove su claim mancante/malformato possono essere eseguite da Sol con un’identità/provider di test controllato. Il revisore verifica soltanto esito HTTP generico e report redatto, mai il token.
4. Logout e riavvio
| Prova | Azione | Risultato atteso | Esito | Note |
|---|---|---|---|---|
| Logout ThothII | usare il comando dell’app | cookie ThothII revocato | ||
| SSO ancora attivo | riaprire ThothII | possibile nuovo accesso senza password; documentare | ||
| Logout Authentik globale | se configurato e in scope | comportamento conforme alla policy locale | ||
| Riavvio core | Sol riavvia in finestra controllata | sessione browser valida secondo TTL/policy | ||
| Provider indisponibile | prova controllata | nuovo login fallisce chiuso e redatto | ||
| Ripristino provider | ripetere diagnosi/login | servizio torna operativo |
Non dichiarare “logout globale” se è stato testato soltanto il logout locale di ThothII.
5. Sessioni PostgreSQL e isolamento
| Prova | Risultato atteso | Esito | Note |
|---|---|---|---|
| Migrazioni | pending=[], drifted=[] |
||
| Schema | thoth_sessions nel database Supabase esistente |
||
| PostgREST | schema non esposto | ||
| RLS | forzata sulle tabelle previste | ||
| Utente A/B | ciascuno vede soltanto le proprie sessioni | ||
| Accesso incrociato | risposta not-found/negata come da contratto | ||
| Admin | accesso trasversale solo secondo permessi documentati | ||
| Credenziale migratore | non montata nel core | ||
| Schema clinico | nessun nuovo privilegio runtime |
6. Sessione completa sotto OIDC
Come utente ordinario, eseguire una domanda innocua approvata e completare F1–F8.
| Prova | Risultato atteso | Esito | Note |
|---|---|---|---|
| Creazione | sessione associata all’identità OIDC | ||
| Gate F1–F8 | tutti presentati e registrati correttamente | ||
| Resume | ritorna alla sessione corretta | ||
| SQL finale | sola lettura e validato | ||
| Persistenza | manifest, artefatti e decisioni in PostgreSQL | ||
| SSE/chat | funzionano live; non richiesti come artefatti persistiti | ||
| Riavvio | sessione di lavoro ancora disponibile |
7. Integrazione e pulizia finale
| Prova | Risultato atteso | Esito | Note |
|---|---|---|---|
| Endpoint temporaneo A | rimosso/non instradato | ||
| Vecchio stack | fermo, non esposto | ||
| Link sidebar | punta solo alla nuova release | ||
| Servizi privati | core/Qdrant/Ollama non pubblicati | ||
| Altri servizi Nginx | invariati e sani | ||
| Rollback | procedura verificata e disponibile | ||
| Evidenze | nessun secret o dato clinico identificabile |
8. Decisione
Decisione finale: PROJECT_B_PASS / PROJECT_B_FAIL / PROJECT_B_PENDING
Revisore e data: ______________________________________
Motivazione sintetica: ______________________________________
Conferma percorso finale “Aritmolab → sidebar → ThothII → SSO”: ______________________________