Stato al 30 settembre
Continuiamo l'indagine sull'autenticazione descritta nell'aggiornamento del 29 settembre. Da allora abbiamo installato ZITADEL nel cluster Food Process, attivato la lettura del repository privato da parte di ArgoCD e verificato il discovery OpenID Connect pubblico su auth.kulinaryos.com con TLS valido. Le nuove immagini del backend Go e dell'app SvelteKit sono state distribuite; i Deployment risultano pronti. Il metodo di accesso precedente rimane nell'app, mentre il nuovo accesso centrale è ancora in verifica.
La presenza di componenti pronti non dimostra che un utente possa già completare il nuovo login. Il primo test della richiesta che avvia il flusso OIDC ha restituito HTTP 503. Il backend ha registrato un errore di discovery; il proxy HTTPS ha registrato un tentativo di connessione verso l'indirizzo pubblico del medesimo nodo del cluster. Il dominio funziona dall'esterno e attraverso il servizio Traefik interno. La causa immediata di questo nuovo errore è quindi il percorso di rete interno al proxy, non il certificato pubblico né le credenziali di un utente.
Una correzione GitOps è in revisione: farà raggiungere a quel proxy il servizio Traefik interno conservando auth.kulinaryos.com come nome TLS e mantenendo la verifica del certificato. La considereremo efficace solo dopo il rollout e un nuovo test dell'avvio OIDC. Non abbiamo ancora attribuito a questa causa il problema di autenticazione segnalato originariamente, né quantificato gli utenti interessati.
Migrazione degli account
L'architettura prevista mantiene ZITADEL come servizio condiviso di identità e il backend Go come responsabile della sessione e dei permessi del prodotto. L'accesso centrale offrirà nome utente e password oppure Google. Il collegamento a una persona già registrata in Kulinaryos richiede una sessione nel suo account e una conferma esplicita: l'uguaglianza delle email, o la loro differenza, non assegna automaticamente ruoli o licenze. Questo protegge anche chi usa un'email aziendale nell'account locale e un indirizzo Gmail su Google.
L'autenticazione locale è abilitata in ZITADEL. Il provider Google non è ancora attivo e il client OAuth è in modalità di test. Prima dell'apertura generale servono prove di accesso, collegamento e recupero, oltre ai link pubblici dell'informativa privacy e dei termini richiesti per la pubblicazione dell'app Google. Le bozze legali sono in revisione, non sono ancora pagine pubbliche.
Email e prossima verifica
Brevo ha accettato e registrato come consegnato un messaggio SMTP transazionale inviato dal nodo di produzione. Questo conferma il trasporto verso il provider, ma non ancora il flusso completo di recupero password dell'app o di ZITADEL. Verificheremo l'invio, la ricezione e l'uso singolo del link con un account controllato, senza esporre token nei log.
Pubblicheremo un altro aggiornamento dopo la prova del percorso OIDC, dei due metodi di accesso e del recupero password. Fino ad allora, l'indagine rimane aperta e non dichiariamo risolto l'incidente iniziale.
Aggiornamento del 30 settembre, ore 19:55 UTC
La correzione del percorso interno del proxy è stata integrata e riconciliata da ArgoCD. Il proxy ora raggiunge ZITADEL attraverso il Traefik interno, conservando il nome TLS pubblico. Abbiamo ripetuto l'avvio del flusso OIDC in produzione: l'API ha restituito HTTP 302 verso l'autorizzazione ZITADEL, invece del precedente HTTP 503. Questo conferma la riparazione di quel passaggio; non dimostra ancora il completamento del login, il collegamento dell'account o il recupero della password. L'incidente originale rimane in indagine.
L'Informativa sulla privacy è pubblicata nel WordPress istituzionale, con un link nel footer. Il testo operativo richiede ancora una revisione legale. I Termini di utilizzo restano in bozza e Google è ancora in modalità di test; l'accesso social non è ancora disponibile al pubblico.
Aggiornamento del 30 settembre, ore 20:20 UTC
Anche i Termini di utilizzo sono pubblicati nel WordPress istituzionale, con un link nel footer. Gli URL pubblici di privacy e termini sono stati registrati nella configurazione OAuth di Google. Entrambi i testi richiedono ancora una revisione legale.
Una prova controllata ha attraversato l'accesso locale di ZITADEL, il ritorno OIDC e la verifica del token da parte dell'API Go. Poiché l'identità usata non è collegata a un account Kulinaryos, l'app ha mostrato correttamente l'istruzione per collegare l'accesso all'account esistente. Brevo risulta attivo come provider SMTP dell'istanza ZITADEL. Restano da provare un account di prodotto collegato, il login Google e l'intero recupero della password.
Aggiornamento del 30 settembre, ore 20:45 UTC
Il provider Google è attivo nell'organizzazione Food Process di ZITADEL; l'app OAuth resta limitata agli utenti di test. Una prova controllata ha completato l'autorizzazione Google e creato un'identità federata con email verificata. ZITADEL ha richiesto esplicitamente la registrazione o il collegamento; il collegamento automatico tramite email è disabilitato. Resta da provare un caso reale di email coincidenti. L'accesso a un account di prodotto continua a richiedere un collegamento esplicito.
La prova ha anche mostrato che l'API Go deve indicare l'organizzazione Food Process nella richiesta OIDC affinché il pulsante Google sia visibile a un nuovo utente. La correzione è in revisione insieme alla configurazione GitOps. La prova isolata ha usato uno stato OIDC di test, correttamente rifiutato al ritorno al prodotto; non dimostra ancora una sessione Kulinaryos tramite Google. Il metodo di accesso precedente resta disponibile. Non apriremo l'accesso Google al pubblico prima di verificare il flusso reale con un account di prodotto collegato, il recupero password e i controlli amministrativi ancora aperti.
Aggiornamento del 30 settembre, ore 21:07 UTC
La correzione è stata integrata e riconciliata da ArgoCD. Le applicazioni radice e API sono sincronizzate e sane; l'API Go è pronta con la nuova immagine immutabile. Una richiesta reale di accesso ha reindirizzato a ZITADEL con lo scope dell'organizzazione Food Process, PKCE, state e nonce. L'opzione Google è comparsa nella schermata di accesso centrale.
Abbiamo selezionato l'identità federata Google registrata nella prova precedente e completato il ritorno OIDC attraverso la vera API Kulinaryos. Poiché l'identità non è ancora collegata a un account del prodotto, l'app ha richiesto correttamente il collegamento e non ha aperto una sessione. Questo conferma che un'identità non collegata non ottiene accesso; restano da provare il collegamento esplicito, una sessione completa e un caso reale di email coincidenti. In questo passaggio non abbiamo ripetuto la schermata di consenso Google.
L'app Google OAuth rimane limitata all'utente di test. Il metodo di accesso precedente resta disponibile. Mancano ancora una prova di recupero password con un account reale, un secondo amministratore con MFA e la revisione legale dei testi di privacy e termini. L'indagine sull'incidente originale resta aperta.
Aggiornamento del 30 settembre, ore 21:22 UTC
Un utente ha richiesto il recupero password per un account esistente. L'API ha restituito la risposta generica prevista, che non rivela se un indirizzo email abbia un account, ma l'invio asincrono è fallito: il Pod tentava ancora il vecchio server SMTP sulla porta 465. Il messaggio non è arrivato. La configurazione dichiarata e il Secret nel cluster puntano già a Brevo; abbiamo trovato variabili precedenti impostate direttamente nel Deployment in esecuzione che avevano priorità su tali risorse.
Una correzione GitOps è in revisione per eliminare questa divergenza, riavviare l'API con un rollout controllato e usare Brevo sulla porta 2525. Dopo la riconciliazione richiederemo un nuovo link e verificheremo ricezione e utilizzo singolo senza pubblicare il token. Il recupero password non è ancora validato e l'incidente resta aperto.
Aggiornamento del 30 settembre, ore 21:33 UTC
La correzione è stata integrata e riconciliata automaticamente da ArgoCD. L'API rimane sana e il suo Pod ora carica Brevo sulla porta 2525. Restano da verificare una nuova richiesta di recupero e la ricezione nella casella email.
Per proteggere gli utenti esistenti manterremo l'accesso attuale con password durante la transizione. Dopo essere entrata in quell'account — anche tramite recupero password, una volta verificata la consegna — la persona potrà collegare esplicitamente un'identità ZITADEL. L'API Go manterrà lo stesso account del prodotto, con organizzazioni e permessi; l'uguaglianza delle email non crea un collegamento. Proveremo casi con email uguali e diverse prima di ampliare l'accesso Google, che resta limitato all'utente di test.
Aggiornamento del 30 settembre, ore 21:39 UTC
Abbiamo ripetuto la richiesta di recupero dopo la correzione: il messaggio di info@kulinaryos.com è arrivato nella casella Gmail dell'account controllato. Questo prova il percorso dall'API Go alla ricezione del messaggio. Il titolare deve ancora usare il link una sola volta, scegliere una nuova password ed entrare; non abbiamo letto né pubblicato il token.
Il piano per gli utenti esistenti mantiene la vecchia password disponibile finché ogni account non abbia un'identità centrale collegata oppure un percorso di recupero assistito e verificato. L'interfaccia di accesso ZITADEL attuale ha un limite: per un account centrale già collegato a Google, inserire lo username può reindirizzare subito a Google senza offrire la scelta della password locale. Per dare entrambe le modalità centrali alla stessa persona serviranno quindi un'interfaccia SvelteKit + Go e prove di sicurezza prima di ritirare l'accesso precedente.
Aggiornamento del 30 settembre, ore 22:33 UTC
Il link dell'email è arrivato, ma ha aperto la pagina di accesso invece del modulo per la nuova password. La consegna tramite Brevo ha funzionato; abbiamo trovato una divergenza tra i percorsi: l'API generava /reset-password, mentre nell'app pubblicata il modulo si trova in /reimposta. Il recupero completo resta non verificato e in questa prova nessuna password è stata cambiata.
La PR infrastrutturale #19 corregge la destinazione delle prossime email. La PR UAT #373 aggiunge un percorso compatibile per i link già inviati. Entrambe richiedono revisione e promozione GitOps; poi proveremo con un account esistente senza registrare o condividere il token. L'accesso precedente con password rimane disponibile.
Aggiornamento del 30 settembre, ore 22:56 UTC
La correzione del percorso è arrivata in produzione tramite GitOps. L'API ora genera i nuovi link verso /reimposta; l'app accetta anche /reset-password per le email inviate prima della modifica. ArgoCD segnala API e app Synced e Healthy, con entrambi i deployment pronti 1/1. Abbiamo aperto il percorso compatibile in UAT e PROD con un token sintetico: entrambi mostrano il modulo «Nuova password», senza riportare alla pagina di accesso.
Abbiamo richiesto un nuovo recupero e la relativa email è arrivata alla casella di prova con il percorso corretto. Il titolare deve ancora impostare personalmente la password e accedere. Solo dopo questa prova verificheremo revoca delle sessioni precedenti, uso singolo del token e collegamento esplicito all'identità ZITADEL. L'accesso precedente rimane disponibile e l'incidente non è ancora chiuso.
Aggiornamento del 1° ottobre, ore 05:05 UTC
Il primo link usato stanotte aveva superato la validità di un'ora. Ne abbiamo richiesto uno nuovo: l'email transazionale è arrivata alla casella di prova, il titolare ha impostato la nuova password e l'app ha mostrato «Password aggiornata». Ha quindi effettuato l'accesso all'account Kulinaryos esistente con la nuova password. Questo verifica il percorso reale di richiesta, consegna, cambio e accesso per tale account, senza registrare o divulgare il token o la password.
Con quella sessione abbiamo avviato e confermato il collegamento esplicito all'identità centrale già provata. Dopo la disconnessione dall'app, «Accedi con Food Process» ha riaperto la dashboard dello stesso account esistente. ZITADEL aveva già autenticato questa identità federata tramite Google in una prova controllata; nell'ultimo accesso abbiamo usato la sessione centrale attiva, senza ripetere il consenso Google.
Durante il collegamento, la conferma non mostrava l'email dell'identità centrale. La causa è stata individuata: in questa configurazione ZITADEL fornisce i dati del profilo dall'endpoint UserInfo, mentre l'API Go leggeva soltanto l'ID token. Le PR UAT #186 e PROD #6 correggono la lettura, confrontano il sub di UserInfo con quello del token e richiedono un'email verificata prima di creare nuovi collegamenti. La correzione attende la promozione; il collegamento controllato è stato autorizzato dal titolare e non apre Google agli altri utenti.
L'app OAuth Google resta in modalità di test. Non abbiamo ancora ripetuto a runtime l'uso singolo del link né la revoca delle altre sessioni dopo il cambio. Restano anche il secondo amministratore con MFA, la revisione legale dei testi pubblici e la scelta di come offrire password centrale e Google alla stessa persona. L'accesso precedente con password rimane disponibile. L'indagine resta aperta finché questi controlli e l'estensione dell'incidente originale non saranno chiariti.