Stato attuale

La pagina principale di accesso a Kulinaryos offre ora due possibilità: e-mail e password, oppure Accedi con Google. Il pulsante Google apre direttamente la scelta dell'account Google, passa da ZITADEL di Food Process e riporta a un account Kulinaryos esistente con una sessione autenticata. Il recupero della password attuale invia un'e-mail transazionale tramite Brevo. Abbiamo verificato il cambiamento in UAT prima di promuoverlo in produzione.

Questo resoconto chiude la fase di consolidamento avviata dopo problemi e attriti nell'autenticazione. L'accesso social richiedeva una pagina intermedia poco chiara, gli account esistenti avevano bisogno di una regola sicura per il collegamento e i link di recupero non aprivano sempre il modulo per la nuova password. L'autorizzazione all'uso del prodotto e le licenze restano di competenza di CRM e ADM; il collegamento di queste decisioni all'identità verrà affrontato in una fase successiva.

Come funziona oggi l'accesso

  • Password esistente: il modulo di Kulinaryos invia le credenziali all'API Go, che autentica l'account attuale del prodotto. Gli utenti non hanno dovuto cambiare password per ottenere l'opzione Google.
  • Recupero: l'API Go crea una richiesta di reimpostazione monouso e invia il messaggio tramite Brevo, usando info@kulinaryos.com come mittente. Il link apre nell'app il modulo per impostare una nuova password; dopo la modifica, l'utente può avviare una nuova sessione con la password scelta.
  • Google: il frontend avvia OIDC sull'API Go con provider=google. L'API reindirizza attraverso ZITADEL, che rimane l'emittente dell'identità. Il flusso conserva PKCE, state e nonce; il browser arriva alla scelta dell'account Google e torna tramite il callback dell'API. Il pulsante compare soltanto quando l'API segnala che il provider è attivo.
  • Ambienti: UAT e produzione hanno client OIDC, callback, credenziali e database del prodotto separati. Condividono l'istanza centrale di ZITADEL e il suo archivio di identità. La restrizione di accesso all'UAT vale per entrambi i metodi.

ZITADEL self-hosted, con PostgreSQL nel cluster Food Process, fornisce il livello centrale di identità e la federazione con Google. Le password legacy del prodotto e il loro recupero sono ancora gestiti dall'API Go e da Brevo. È importante chiarire questo confine: la presenza di ZITADEL nel flusso Google non significa che tutte le password esistenti siano già state migrate.

Collegamento automatico senza approvazioni individuali

Quando Google conferma un indirizzo Gmail verificato che coincide con l'e-mail di un account esistente, l'API collega automaticamente l'identità centrale a quell'account. L'utente entra nell'account che aveva già, senza una registrazione duplicata né un'approvazione individuale dei responsabili. Se gli indirizzi sono diversi, la persona può dimostrare il possesso dell'account esistente con la propria password e completare il collegamento autonomamente. La somiglianza tra nomi o indirizzi non autorizza un collegamento automatico.

Questa regola separa autenticazione e autorizzazione. Nel disegno dell'ecosistema, il CRM è l'autorità per registrazioni, licenze e permessi d'uso; scegliere Google o password non crea una licenza e non amplia i privilegi. Anche la politica di accesso riservato all'UAT si applica allo stesso modo a entrambi i metodi.

Che cosa è cambiato il 3 ottobre

Abbiamo prima promosso l'API con il collegamento automatico degli account esistenti e l'interfaccia pubblica in sei lingue, compresi accesso e recupero. Abbiamo poi aggiornato ZITADEL alla v4.19.2, dopo aver verificato un backup esterno e un ripristino isolato del database. La versione precedente era interessata dall'avviso di sicurezza GHSA-g8gj-gq47-xgf4. L'aggiornamento ha preceduto l'attivazione dell'ingresso diretto con Google in produzione.

Successivamente abbiamo distribuito l'API Go che avvia OIDC direttamente con il provider Google e il frontend con il pulsante Accedi con Google. Il precedente pulsante generico “Food Process” è stato rimosso dalla pagina principale di accesso. Ogni promozione ha usato un'immagine immutabile tramite GitOps; l'API è stata verificata prima di cambiare l'immagine dell'app.

Evidenze di funzionamento

  • In UAT, un vero accesso Google ha collegato un'identità a un account già registrato ed è arrivato alla dashboard senza creare un secondo account. Abbiamo anche completato il recupero tramite Brevo, chiuso la sessione e effettuato nuovamente l'accesso con la nuova password.
  • In produzione, l'API pubblicata ha segnalato Google come attivo; i reindirizzamenti hanno seguito API → ZITADEL → Google. Nell'interfaccia pubblicata, il pulsante ha aperto la scelta dell'account Google e riportato un account esistente alla dashboard autenticata.
  • L'accesso con password, l'uscita dalla sessione e il recupero via e-mail erano già stati esercitati in produzione durante questo consolidamento. Le relative funzioni restano disponibili accanto al nuovo pulsante.
  • Dopo la promozione, API, frontend e servizio di identità erano pronti e ArgoCD è tornato a Synced/Healthy. Un certificato in attesa per prova.kulinaryos.com, relativo a una prova pubblica separata, è stato risolto pubblicando il record DNS. Questo host è esterno al flusso di accesso.

Prossimi passi

Questo rilascio offre agli utenti attuali una base funzionante. La prossima sessione di ingegneria rafforzerà le politiche di identità: MFA per gli amministratori, revisione di sessioni e recupero, limiti contro gli abusi, osservabilità e avvisi. Poi collegheremo l'autenticazione alle decisioni del CRM su registrazione, autorizzazione e licenze. Brevo resta il servizio di e-mail transazionali di Food Process.

Registro delle modifiche