Aggiornamento del 16 ottobre: il primo rilascio UAT e ulteriori prove di accettazione sono già avvenuti. Questo testo conserva lo stato del 7 ottobre; consulta avanzamento e attività aperte.

Che cosa è stato consegnato

Il 7 ottobre abbiamo completato un'altra fase di sviluppo dell'autenticazione e dell'autorizzazione di Kulinaryos. Le modifiche coordinate ad API Go, app, CRM, ADM e FIC GARA sono state integrate nei repository UAT. Tutte e cinque le pipeline sono terminate con successo e hanno pubblicato immagini immutabili. La presenza e il digest di ogni immagine sono stati confermati nel registro.

Questa fase non è ancora stata distribuita in UAT né promossa in produzione. La pubblicazione delle immagini prepara il rilascio, ma il consolidamento completo richiede ancora una migrazione revisionata, la distribuzione tramite GitOps e i test autenticati nell'ambiente. Questo post prosegue il resoconto del 3 ottobre, relativo alle modifiche di accesso e recupero pubblicate allora.

Una persona, permessi espliciti

La nuova implementazione usa l'identificatore interno della persona e il collegamento all'identità emessa da ZITADEL. L'e-mail è un contatto modificabile; licenze, appartenenze alle organizzazioni e poteri amministrativi seguono collegamenti espliciti alla persona. Cambiare contatto o metodo di accesso non trasferisce questi diritti.

La registrazione di una persona crea anche il suo profilo CRM nella stessa transazione. Il CRM registra l'origine commerciale e il ciclo delle licenze; l'API Go verifica i diritti attuali a ogni richiesta. L'accesso considera organizzazione, modulo, stato e validità. Se i diritti non possono essere confermati, l'accesso viene negato.

Accesso, recupero e sessioni

App, CRM, ADM e FIC hanno ricevuto flussi coordinati di Google tramite ZITADEL e di collegamento gestito dal titolare. Il collegamento automatico richiede le prove del contatto previste dalla politica. Se i contatti differiscono, il titolare può dimostrare il possesso dell'account esistente senza una coda di approvazioni individuali.

Le sessioni usano cookie protetti e controlli di revoca sul server. L'uscita e il recupero della password aggiornano lo stato della sessione; il recupero verifica il contatto attuale e usa link monouso. I test coprono anche modifiche concorrenti di contatto e password. Brevo resta il servizio di e-mail transazionali.

Licenze e deleghe

L'emissione richiede ora un'autorizzazione con ambito esplicito: beneficiario, prodotto, paese, validità e limite di emissione. Delega, emissione e revoca lasciano registrazioni di audit. I percorsi commerciali verificano la conferma richiesta prima di attivare i diritti; un pagamento in attesa non sblocca il prodotto.

Sospensione, scadenza e revoca vengono verificate durante l'uso. L'interfaccia segue la decisione dell'API, anche per una sessione già aperta. La proposta infrastrutturale limita le origini UAT e include FIC nelle verifiche di promozione e delle immagini.

Evidenze di questa fase

  • L'harness dell'API, con PostgreSQL temporaneo, OIDC sintetico e cattura delle e-mail, ha superato 1.624 test per il codice UAT e 1.607 per il codice preparato per la produzione, senza errori o test saltati. I test sintetici non dimostrano il funzionamento reale di Google o la consegna tramite Brevo.
  • Check, test e build locali dei frontend UAT sono passati: 1.264 test nell'app, 61 nel CRM, 55 nell'ADM e 98 nel FIC. Anche le pipeline di pubblicazione sono terminate con successo.
  • I preflight in sola lettura hanno inventariato gli ambienti attuali. Rendering, schema dei manifest e verifiche architetturali sono passati per la proposta infrastrutturale. Le sonde pubbliche hanno dimostrato salute e rifiuto dell'accesso anonimo; non dimostrano la matrice autenticata.

Che cosa resta da completare

La prossima fase è revisionare i collegamenti amministrativi tramite UUID, le associazioni dello staff e la riconciliazione delle licenze esistenti. Seguono la migrazione UAT autorizzata e la promozione delle cinque immagini tramite GitOps, con coordinate di rollback registrate.

Dopo la distribuzione, l'accettazione deve usare account controllati: password, vero accesso Google, collegamento del titolare, recupero consegnato tramite Brevo, delega, emissione, sospensione e revoca. Deve anche dimostrare il rifiuto tra organizzazioni e moduli e il comportamento di app, CRM, ADM e FIC per la stessa persona con poteri diversi. La preparazione del codice di produzione resta separata da qualsiasi distribuzione in produzione.

Registro delle modifiche