Status on 30 September

We are continuing the authentication investigation reported on 29 September. Since then, we have installed ZITADEL in the Food Process cluster, enabled ArgoCD to read the private repository, and verified public OpenID Connect discovery at auth.kulinaryos.com with a valid TLS certificate. The new Go backend and SvelteKit app images have been deployed, and their Deployments are ready. The previous sign-in method remains in the app while central sign-in is still being tested.

Ready components do not prove that a user can complete the new login. The first request to start the OIDC flow returned HTTP 503. The backend logged a discovery failure; the HTTPS proxy logged an attempt to connect to the cluster node's own public address. The domain works externally and through the internal Traefik Service. The immediate cause of this new failure is therefore the proxy's internal network path, not the public certificate or a user's credentials.

A GitOps repair is under review. It will route that proxy to the internal Traefik Service while retaining auth.kulinaryos.com as the TLS name and preserving certificate validation. We will consider it effective only after rollout and a fresh OIDC initiation test. We have not established that this is the cause of the originally reported authentication problem, or quantified the affected users.

Account migration

The planned architecture uses ZITADEL as the shared identity service and the Go backend to manage product sessions and permissions. Central sign-in will offer username and password or Google. Linking a central identity to an existing Kulinaryos user requires a session in that product account and explicit confirmation. Matching or different email addresses do not assign roles or licences automatically. This also protects users whose local account uses a work email while their Google account uses Gmail.

Local authentication is enabled in ZITADEL. The Google provider is not yet active, and the OAuth client remains in testing. Before general availability, we need to test sign-in, linking and recovery, and publish privacy and terms links required for the production Google app. The legal texts are drafts under review, not public pages yet.

Email and next verification

Brevo accepted a transactional SMTP message from the production node and recorded it as delivered. This verifies transport to the provider, not the complete password-reset flow in the app or ZITADEL. We will test sending, receipt and one-time link use with a controlled account without exposing tokens in logs.

We will publish another update after testing the OIDC path, both sign-in methods and password recovery. The investigation remains open, and we are not declaring the original incident resolved.

Update on 30 September, 19:55 UTC

The internal proxy route fix was merged and reconciled by ArgoCD. The proxy now reaches ZITADEL through internal Traefik while retaining the public TLS name. We repeated OIDC initiation in production: the API returned HTTP 302 to ZITADEL authorization instead of the earlier HTTP 503. This confirms that step is repaired; it does not yet prove a completed login, account linking or password recovery. The original incident remains under investigation.

The privacy notice is now public on the institutional WordPress site, with a footer link. This operational version still needs legal review. Terms of Use remain a draft and Google is still in testing; social sign-in is not yet open to the public.

Update on 30 September, 20:20 UTC

The Terms of Use are now public on the institutional WordPress site, with a footer link. Both public legal URLs are saved in the Google OAuth branding settings. The texts still need legal review.

A controlled test traversed local ZITADEL sign-in, the OIDC return and token verification by the Go API. Because the test identity is not linked to a Kulinaryos account, the app correctly prompted for linking to an existing account. Brevo is listed as the active SMTP provider for the ZITADEL instance. A linked product account, Google sign-in and complete password recovery still need end-to-end tests.

Update on 30 September, 20:45 UTC

The Google provider is active in the Food Process ZITADEL organization; the OAuth app remains limited to test users. A controlled test completed Google authorization and created a federated identity with a verified email. ZITADEL explicitly asked whether to register or link the identity; automatic email linking is disabled. A real matching-email case still needs a test. Access to an existing product account still requires explicit linking.

The test also showed that the Go API must specify the Food Process organization in its OIDC request for a new user to see the Google option. That change and the corresponding GitOps configuration are under review. The isolated probe used a test OIDC state, correctly rejected on return to the product, so it does not yet prove a Kulinaryos session through Google. The existing sign-in remains available. We will not open Google sign-in to the public before validating the real flow with a linked product account, password recovery and the remaining administrator controls.

Update on 30 September, 21:07 UTC

The fix was merged and reconciled by ArgoCD. The root and API applications are synced and healthy; the Go API is ready on the new immutable image. A real sign-in initiation redirected to ZITADEL with the Food Process organization scope, PKCE, state and nonce. The Google option appeared on the central login screen.

We selected the Google-federated identity registered in the earlier test and completed the OIDC return through the real Kulinaryos API. Because that identity is not yet linked to a product account, the app correctly required linking and did not open a session. This confirms that an unlinked identity receives no access; explicit linking, a complete product session and a real matching-email case still need testing. We did not repeat Google's consent screen in this step.

The Google OAuth app remains limited to its test user. Existing sign-in is still available. A real-account password reset, a second administrator with MFA, and legal review of the privacy and terms texts remain pending. Investigation of the original incident remains open.

Update on 30 September, 21:22 UTC

A user requested a password reset for an existing account. The API returned the expected generic response, which does not reveal whether an email address has an account, but the asynchronous send failed: the Pod still tried the old SMTP server on port 465. The message did not arrive. The declared configuration and cluster Secret already target Brevo; we found older variables set directly on the running Deployment that took precedence over those resources.

A GitOps repair is under review to remove this drift, restart the API in a controlled rollout and use Brevo on port 2525. After reconciliation, we will request a fresh link and verify mailbox receipt and single use without publishing the token. Password recovery is not yet validated, and the incident remains open.

Update on 30 September, 21:33 UTC

The repair was merged and automatically reconciled by ArgoCD. The API remains healthy, and its Pod now loads Brevo on port 2525. A fresh reset request and mailbox receipt still need verification.

To protect existing users, we will keep the current password login during the transition. After signing in to that account — including by password recovery once mail delivery is validated — the user can explicitly link a ZITADEL identity. The Go API will retain the same product account, organizations and permissions; matching email addresses do not create a link. We will test both matching and different emails before widening Google access, which remains restricted to the test user.

Update on 30 September, 21:39 UTC

We repeated the reset request after the repair: the message from info@kulinaryos.com reached the controlled account's Gmail inbox. This proves the path from the Go API to message receipt. The account owner still needs to use the link once, choose a new password and sign in; we did not read or publish the token.

The plan for existing users keeps the old password method available until every account has either a linked central identity or a verified assisted recovery route. There is a limitation in ZITADEL's current login UI: for a central account already linked to Google, entering its username can redirect straight to Google without offering a local password choice. Providing both central methods to the same person therefore requires a custom SvelteKit + Go interface and security tests before we retire the old login.

Update on 30 September, 22:33 UTC

The email link arrived but opened the sign-in page rather than the new-password form. Brevo delivery worked; we found a route mismatch: the API generated /reset-password, while the deployed app has the form at /reimposta. The complete recovery flow remains unverified, and this test did not change a password.

Infrastructure PR #19 corrects the destination for future emails. UAT PR #373 adds a compatibility route for links already sent. Both require review and GitOps promotion; then we will test with an existing account without logging or sharing the token. The previous password sign-in remains available.

Update on 30 September, 22:56 UTC

The route repair reached production through GitOps. The API now generates new links to /reimposta, and the app also accepts /reset-password for emails sent before the change. ArgoCD reports both API and app Synced and Healthy, with each deployment ready 1/1. We opened the compatibility path in UAT and PROD with a synthetic token: both display the “Nuova password” form instead of sign-in.

We requested a fresh reset and the test mailbox received its email with the corrected path. The account owner still has to set the password and sign in personally. Only then can we verify old-session revocation, single-use tokens and explicit linking to the ZITADEL identity. The previous sign-in stays available, and the incident remains open.

Update on 1 October, 05:05 UTC

The first link used overnight had passed its one-hour lifetime. We requested a fresh one: the transactional email reached the test inbox, the account owner set a new password, and the app displayed “Password aggiornata”. The owner then signed in to the existing Kulinaryos account with that password. This verifies request, delivery, password change and sign-in for that account without recording or disclosing the token or password.

From that session we started and confirmed an explicit link to the central identity tested earlier. After signing out of the app, “Accedi con Food Process” returned to the dashboard of the same existing account. ZITADEL had previously authenticated this federated identity through Google in a controlled test; this latest sign-in reused its active central session and did not repeat Google's consent screen.

The linking confirmation did not show the central identity's email. We traced this to claim handling: in this configuration ZITADEL supplies profile data through UserInfo, while the Go API read only the ID token. UAT PR #186 and PROD PR #6 retrieve UserInfo, match its sub to the verified token, and require a verified email before creating new links. The fix is awaiting promotion; the controlled link above was approved by the account owner and does not open Google access to other users.

The Google OAuth app remains in testing. We have not yet repeated single-use token and other-session revocation checks in production after the password change. A second administrator with MFA, legal review of the public texts and the design for offering both central password and Google to one person also remain open. Existing password sign-in stays available. We keep the investigation open until those controls and the scope of the original incident are established.