Situação em 30 de setembro
Continuamos a investigação da autenticação comunicada em 29 de setembro. Desde então, instalamos o ZITADEL no cluster da Food Process, habilitamos o ArgoCD a ler o repositório privado e verificamos a descoberta pública de OpenID Connect em auth.kulinaryos.com com certificado TLS válido. As novas imagens do backend Go e do app SvelteKit foram distribuídas, e os Deployments estão prontos. A forma anterior de login permanece no app enquanto testamos o acesso central.
Componentes prontos não comprovam que uma pessoa já consiga concluir o novo login. A primeira requisição de início do fluxo OIDC retornou HTTP 503. O backend registrou falha na descoberta do provedor; o proxy HTTPS registrou uma tentativa de conexão ao endereço público do próprio nó do cluster. O domínio funciona externamente e pelo serviço Traefik interno. A causa imediata desta nova falha é, portanto, o caminho de rede interno do proxy, não o certificado público nem a senha de um usuário.
Uma correção GitOps está em revisão. Ela direcionará o proxy ao serviço Traefik interno, mantendo auth.kulinaryos.com como nome TLS e preservando a validação do certificado. Só a consideraremos eficaz depois da reconciliação e de um novo teste de início OIDC. Ainda não atribuímos a essa causa o problema de autenticação relatado originalmente nem quantificamos as pessoas afetadas.
Migração das contas
A arquitetura prevista usa o ZITADEL como serviço compartilhado de identidade e o backend Go para cuidar da sessão e das permissões do produto. O login central oferecerá usuário e senha ou Google. Vincular uma identidade central a uma conta Kulinaryos existente exige uma sessão nessa conta e confirmação explícita. Emails iguais ou diferentes não concedem funções ou licenças automaticamente. Isso também protege quem usa email corporativo na conta local e Gmail no Google.
A autenticação local está habilitada no ZITADEL. O provedor Google ainda não está ativo, e o cliente OAuth permanece em teste. Antes da abertura geral, precisamos testar login, vínculo e recuperação, além de publicar os links de privacidade e termos exigidos para o app Google em produção. Os textos legais são minutas em revisão, não páginas públicas.
Email e próxima verificação
O Brevo aceitou uma mensagem SMTP transacional enviada do nó de produção e a registrou como entregue. Isso comprova o transporte até o provedor, mas ainda não o fluxo completo de redefinição de senha no app ou no ZITADEL. Testaremos envio, recebimento e uso único do link com uma conta controlada, sem expor tokens nos logs.
Publicaremos outra atualização após testar o caminho OIDC, as duas formas de login e a recuperação de senha. A investigação continua aberta; não declaramos resolvido o incidente original.
Atualização de 30 de setembro, 19h55 UTC
A correção da rota interna do proxy foi mesclada e reconciliada pelo ArgoCD. O proxy agora alcança o ZITADEL pelo Traefik interno sem trocar o nome TLS público. Repetimos o início do fluxo OIDC em produção: a API retornou HTTP 302 para a autorização do ZITADEL, em vez do HTTP 503 anterior. Isso confirma o reparo desse passo; ainda não comprova login completo, vínculo de conta ou recuperação de senha. O incidente original permanece em investigação.
A Informativa sulla privacy foi publicada no WordPress institucional, com link no rodapé. O texto operacional ainda precisa de revisão jurídica. Os Termos de Uso continuam em minuta, e o Google permanece em teste; ainda não abrimos o login social ao público.
Atualização de 30 de setembro, 20h20 UTC
Os Termos de Uso também foram publicados no WordPress institucional, com link no rodapé. Os URLs públicos de privacidade e termos estão cadastrados na marca OAuth do Google. Ambos os textos ainda exigem revisão jurídica.
Uma prova controlada percorreu o login local do ZITADEL, o retorno OIDC e a verificação do token pela API Go. Como a identidade usada não está vinculada a uma conta Kulinaryos, a aplicação mostrou corretamente a instrução para vincular o acesso à conta existente. O Brevo consta como provedor SMTP ativo da instância ZITADEL. Ainda faltam o teste com conta de produto vinculada, a configuração e prova do Google e o fluxo completo de recuperação de senha.
Atualização de 30 de setembro, 20h45 UTC
O provedor Google está ativo na organização Food Process do ZITADEL, e o aplicativo OAuth continua limitado a usuários de teste. Um teste controlado concluiu a autorização do Google e criou uma identidade federada com e-mail verificado. O ZITADEL pediu explicitamente registro ou vínculo; a vinculação automática por e-mail está desativada. Ainda precisamos testar um caso real de e-mails coincidentes. O acesso a uma conta de produto continua dependendo de vínculo explícito.
O teste também revelou que a API Go precisa indicar a organização Food Process na requisição OIDC para que o botão Google apareça para uma pessoa nova. A correção está em revisão junto com a configuração GitOps correspondente. A prova isolada usou um estado OIDC de teste, rejeitado corretamente no retorno ao produto; por isso ainda não comprova uma sessão Kulinaryos via Google. O acesso anterior permanece disponível. Não abriremos o login Google ao público antes de validar o fluxo real com uma conta de produto vinculada, a recuperação de senha e os controles administrativos pendentes.
Atualização de 30 de setembro, 21h07 UTC
A correção foi mesclada e reconciliada pelo ArgoCD. O aplicativo raiz e a API estão sincronizados e saudáveis; a API Go está pronta com a imagem imutável nova. Uma requisição real de início de login retornou ao ZITADEL com o escopo da organização Food Process, PKCE, estado e nonce. A opção Google apareceu na tela de login central.
Selecionamos no ZITADEL a identidade federada Google cadastrada no teste anterior e concluímos o retorno OIDC pela API real do Kulinaryos. Como essa identidade ainda não está vinculada a uma conta do produto, o aplicativo exigiu corretamente o vínculo e não abriu uma sessão. Isso confirma que uma identidade sem vínculo não recebe acesso; ainda precisamos provar o vínculo explícito, uma sessão completa e um caso real de e-mails coincidentes. Neste passo não repetimos a tela de consentimento do Google.
O Google OAuth continua limitado ao usuário de teste. O login anterior segue disponível. O teste de redefinição de senha com uma conta real, o segundo administrador com MFA e a revisão jurídica dos textos de privacidade e termos ainda estão pendentes. A investigação do incidente original continua aberta.
Atualização de 30 de setembro, 21h22 UTC
Uma pessoa solicitou a redefinição da senha de sua conta existente. A API respondeu de forma genérica, como previsto para não revelar quais e-mails têm conta, mas o envio assíncrono falhou: o pod ainda tentava o servidor SMTP antigo na porta 465. Por isso o e-mail não chegou. A configuração declarada e o Secret no cluster já apontam para o Brevo; verificamos que variáveis antigas, inseridas diretamente no Deployment em execução, tinham prioridade sobre essa configuração.
Preparamos uma correção GitOps para retirar essa divergência, reiniciar a API de forma controlada e usar o Brevo na porta 2525. Ela está em revisão. Após a reconciliação, repetiremos a solicitação, conferiremos o recebimento e o uso único do link sem publicar o token. A recuperação de senha ainda não está validada, e o incidente permanece aberto.
Atualização de 30 de setembro, 21h33 UTC
A correção foi mesclada e reconciliada automaticamente pelo ArgoCD. A API continua saudável, e o pod agora carrega o servidor Brevo na porta 2525. O envio de um novo pedido de reset e o recebimento do e-mail ainda precisam ser comprovados.
Para proteger os usuários atuais, manteremos o login por senha já existente durante a transição. Depois de entrar nessa conta — inclusive por recuperação de senha, quando o envio estiver validado — a pessoa poderá vincular explicitamente uma identidade ZITADEL. A API preservará a mesma conta, organizações e permissões; igualdade de e-mail não cria vínculo. Testaremos casos com e-mails iguais e diferentes antes de ampliar o acesso Google, que permanece restrito ao usuário de teste.
Atualização de 30 de setembro, 21h39 UTC
Repetimos o pedido de reset após a correção: a mensagem de info@kulinaryos.com chegou à caixa Gmail da conta controlada. Isso comprova o caminho da API Go até o recebimento da mensagem. O titular ainda precisa usar o link uma vez, escolher a nova senha e entrar na conta; não lemos nem publicamos o token.
O plano para usuários atuais mantém a senha anterior disponível até que cada conta tenha uma identidade central vinculada ou uma recuperação assistida verificada. Há um limite da interface de login atual do ZITADEL: para uma conta central já vinculada ao Google, informar o username pode levar diretamente ao Google, sem oferecer a escolha de senha local. Portanto, a opção entre Google e senha central para a mesma pessoa ainda exige uma interface própria em SvelteKit + Go, com testes de segurança, antes de retirarmos o login anterior.
Atualização de 30 de setembro, 22h33 UTC
O link do e-mail chegou, mas abriu a tela de login em vez do formulário de nova senha. A entrega pelo Brevo funcionou; encontramos uma divergência de rota: a API gerava /reset-password, enquanto o app publicado oferece o formulário em /reimposta. A recuperação completa segue não validada e nenhuma senha foi alterada neste teste.
A PR de infraestrutura #19 corrige o destino dos próximos e-mails. A PR UAT #373 mantém os links antigos utilizáveis ao adicionar uma rota de compatibilidade. Ambas exigem revisão e promoção pelo fluxo GitOps; depois faremos um teste com conta existente, sem registrar ou compartilhar o token. O login anterior por senha permanece disponível.
Atualização de 30 de setembro, 22h56 UTC
A correção da rota chegou à produção por GitOps. A API agora gera novos links para /reimposta, e o app também aceita /reset-password para mensagens enviadas antes da mudança. O ArgoCD informa API e app Synced e Healthy, com ambos os deployments prontos 1/1. Abrimos a rota de compatibilidade em UAT e PROD com um token sintético: nos dois ambientes apareceu o formulário “Nuova password”, sem voltar ao login.
Pedimos uma nova redefinição e o e-mail chegou à caixa de teste com o caminho correto. O titular ainda precisa definir a senha pessoalmente e entrar na conta. Depois disso, verificaremos a revogação das sessões anteriores, o uso único do token e o vínculo explícito com a identidade ZITADEL. O login anterior continua disponível, e o incidente permanece aberto.
Atualização de 1º de outubro, 05h05 UTC
O primeiro link usado nesta madrugada já havia ultrapassado sua validade de uma hora. Solicitamos outro: o e-mail transacional chegou à caixa de teste, o titular definiu a nova senha e o app exibiu “Password aggiornata”. Em seguida, ele entrou na conta Kulinaryos existente com a nova senha. Isso valida o caminho real de solicitação, entrega, troca e login para essa conta, sem registrar ou divulgar o token ou a senha.
Com essa sessão, iniciamos e confirmamos o vínculo explícito com a identidade central previamente testada. Depois de sair do app, “Accedi con Food Process” retornou ao dashboard da mesma conta existente. O ZITADEL já havia autenticado essa identidade federada pelo Google em uma prova controlada; neste último acesso usamos sua sessão central ativa, sem repetir a tela de consentimento do Google.
Durante o vínculo, a confirmação não mostrou o e-mail da identidade central. Encontramos a causa: nesta configuração, o ZITADEL fornece os dados de perfil pelo endpoint UserInfo, mas a API Go lia apenas o ID token. As PRs UAT #186 e PROD #6 corrigem a leitura, verificam que o sub do UserInfo coincide com o token e exigem e-mail verificado antes de criar novos vínculos. O reparo ainda aguarda promoção; o vínculo controlado acima foi autorizado pelo titular e não libera o Google para outros usuários.
O OAuth do Google permanece em modo de teste. Ainda não repetimos em runtime o uso único do link nem a revogação de outras sessões após a troca, e faltam o segundo administrador com MFA, a revisão jurídica dos textos públicos e a decisão sobre como oferecer senha central e Google à mesma pessoa. O login anterior por senha continua disponível. Mantemos a investigação aberta até concluir esses controles e medir o alcance do incidente original.