Como testar o GitLab Email OTP em 2026? Desenvolvedores validam o código de login

A documentação oficial do GitLab informa que o rollout do Email OTP no GitLab.com começou em 2026 (documentação de desenvolvimento do Email OTP). Isso não significa que o GitLab Self-Managed tenha a mesma política ou configuração. Para testar com segurança, valide primeiro o estado e o fluxo de login numa instância isolada; depois, use um endereço controlado para confirmar o recebimento da mensagem e concluir o login. Não use endereço temporário em contas de produção ou importantes.

Para administradores do GitLab Self-Managed: para confirmar a configuração efetiva da instância e os limites do recurso.
Para QA: para verificar o recebimento do código e o fechamento do fluxo em contas de teste próprias.
Para desenvolvedores: para separar a captura local da mensagem, a aceitação do código e a criação de uma sessão autenticada.

Última revisão: 26 de outubro de 2026. As informações sobre rollout e configuração foram conferidas na documentação oficial do Email OTP e da autenticação de dois fatores.

O que o teste precisa provar

Antes de alterar configurações, defina qual evidência a equipe precisa produzir. Um teste de login pode ter resultados diferentes, e passar numa etapa não comprova automaticamente as seguintes:

• Geração e acionamento: a instância reconheceu a conta e iniciou o fluxo de Email OTP depois da autenticação inicial.
• Conteúdo e recebimento: uma mensagem correspondente à tentativa chegou a um coletor local ou a uma caixa controlada.
• Aceitação do código: a aplicação aceitou o código enviado para aquela tentativa.
• Fechamento do login: o navegador ou cliente terminou numa sessão autenticada, e não apenas numa página que parece indicar sucesso.

O escopo também precisa separar três alvos. GitLab.com é o serviço hospedado, cuja política é definida pelo próprio serviço. GitLab Self-Managed é uma instalação administrada pela equipe, com versão e configurações próprias. GDK serve para desenvolvimento local e pode usar um caminho de envio diferente daquele de uma instalação acessível aos usuários. A evidência obtida num desses alvos não confirma automaticamente o comportamento dos outros.

A documentação de usuário do GitLab descreve a exigência de MFA no GitLab.com para login com nome de usuário e senha a partir de abril de 2026 e explica quando o Email OTP pode ser aplicado se outros fatores não estiverem configurados (orientações oficiais sobre autenticação de dois fatores). Esse contexto descreve o serviço hospedado. Não use essa política como prova de que o recurso está habilitado por padrão na instalação da equipe.

Decisão de teste: escolha a evidência que corresponde ao objetivo

Marque os itens que correspondem ao critério de aceitação. Se o objetivo escolhido exigir uma evidência que não foi marcada como concluída, não registre o ensaio como aprovado.

• [ ] Quero testar a lógica do código ou a interface, sem provar entrega externa. Escolha a captura local. Ela pode mostrar que a aplicação gerou a mensagem e a encaminhou ao coletor. Registre esse limite no resultado. Se a aplicação não entrar na etapa do código, investigue primeiro o estado do fluxo e a configuração da instância.
• [ ] Quero provar que uma caixa recebeu a mensagem. Escolha um endereço controlado pela equipe e confira a mensagem nessa caixa. Se a equipe não puder acessar o endereço ou confirmar o recebimento, recue para um teste de lógica com captura local e classifique-o como evidência parcial.
• [ ] Quero aceitar o login de ponta a ponta. Exija as três evidências: mensagem correspondente à tentativa, código aceito e sessão autenticada. Se faltar qualquer uma, o teste não comprova o fechamento do fluxo; volte à etapa que falhou e registre o resultado como parcial ou reprovado.
• [ ] O alvo é GitLab.com, uma conta real importante ou uma identidade de produção. Não use endereço temporário para esse ensaio. Use o processo autorizado e um endereço duradouro sob controle do titular ou da organização. Se for necessário testar o comportamento da equipe, faça isso numa instância isolada com uma conta não produtiva.

Essa divisão evita uma conclusão enganosa: “a mensagem apareceu no coletor” não equivale a “uma caixa externa recebeu o e-mail”; “o código foi aceito” também não equivale, por si só, a “o teste confirmou uma sessão autenticada”.

Administradores: confirme os limites da configuração

O administrador deve registrar a versão da instância e inspecionar as opções disponíveis naquela instalação. Os nomes, a disponibilidade e o efeito das configurações podem depender do produto e da versão. Consulte a documentação oficial aplicável, em vez de copiar valores de um tutorial dirigido ao GitLab.com.

A documentação da API de configurações pode ajudar a verificar as configurações expostas pela API. Porém, não presuma que qualquer parâmetro com nome parecido controla o Email OTP. Confirme na documentação do recurso quais opções se aplicam e verifique o estado real da instância. Se a equipe consultar a interface administrativa, registre os valores observados e o caminho usado para encontrá-los, para que outra pessoa possa reproduzir a verificação.

Também é importante não confundir mecanismos que parecem relacionados por envolverem identidade ou e-mail:

• Email OTP é um código de uso único enviado por e-mail como parte do fluxo de autenticação documentado pelo GitLab.
• Confirmação de endereço de e-mail trata da verificação de uma conta ou de seu endereço; isso não demonstra que o segundo fator de login está configurado ou foi testado. Consulte a documentação de verificação de e-mail da conta.
• TOTP e WebAuthn são outros fatores de autenticação. Testar um desses métodos não valida automaticamente o caminho de Email OTP.

As restrições de login também podem interferir no que a conta consegue fazer. Consulte as restrições de login para instalações administradas e anote as condições relevantes para o ensaio. Não presuma que a ausência de uma etapa de código significa falha no envio: a conta pode estar seguindo outro método, a configuração pode não se aplicar, ou o fluxo pode ter sido bloqueado antes de chegar ao e-mail.

Desenvolvedores: separe o estado da aplicação do transporte

Para validar o caminho da aplicação, associe cada tentativa a uma conta de teste e a uma execução identificável. Não use dados de uma pessoa real. Faça login com as credenciais da conta isolada e observe se o fluxo entra na etapa de Email OTP. Se a instância estiver configurada para outro método ou se a conta não estiver sujeita a esse fluxo, não interprete a ausência do campo de código como erro de entrega.

Quando o ambiente usa um capturador local, abra a mensagem correspondente à tentativa e verifique o destinatário, o contexto do login e o código apresentado. A captura é útil para testar a montagem do conteúdo e a integração entre a aplicação e o capturador. Ela não demonstra que servidores externos aceitaram a mensagem, que a caixa destinatária a recebeu ou que filtros de terceiros a classificaram como esperado.

Para fechar a validação, envie o código no fluxo correspondente e observe o estado final da aplicação. A evidência precisa distinguir estes resultados:

• A aplicação exibiu a etapa de código.
• A mensagem correspondente foi encontrada no coletor ou na caixa controlada.
• O código foi aceito ou rejeitado pelo fluxo.
• A sessão autenticada foi criada e permaneceu acessível na navegação protegida prevista pelo teste.

Não registre o código em relatórios compartilhados, capturas de tela públicas ou sistemas de observabilidade sem controles adequados. Para a evidência de QA, basta preservar a relação entre a execução, o resultado e a mensagem sem expor o segredo. Se o código precisar ser guardado para uma análise autorizada, limite o acesso e remova-o quando o teste terminar.

Uma boa implementação de automação também deve distinguir falhas de aplicação das falhas de transporte. Por exemplo, uma execução pode confirmar que o login chegou à etapa de Email OTP, mas falhar porque a mensagem não apareceu no coletor. Nesse caso, o relatório deve apontar que o estado de aplicação foi alcançado, mas que o recebimento não foi comprovado. Evite uma única asserção genérica, como “login falhou”, quando a evidência permite indicar a etapa exata.

QA: valide o recebimento de forma controlada

Um endereço controlado permite verificar a mensagem numa caixa real sem envolver a caixa de trabalho de uma pessoa. Antes de executar, confirme que a equipe tem acesso ao endereço e que seu uso é permitido pela política interna. Para um ensaio que precisa comprovar entrega externa, não substitua a caixa por uma captura local nem trate uma mensagem simulada como prova de recebimento.

Siga um roteiro que outra pessoa da equipe possa repetir:

• Escolha uma conta de teste isolada e confirme que ela não é uma conta administrativa ou de produção.
• Registre a versão da instância, o ambiente usado e as configurações pertinentes ao fluxo.
• Inicie um login novo com essa conta e anote se a aplicação solicita o código.
• Verifique a caixa controlada e associe a mensagem à tentativa correta, sem copiar o segredo para um relatório amplo.
• Envie o código no fluxo da instância e registre o resultado apresentado.
• Confirme a sessão usando a navegação protegida prevista pelo caso de teste; não conclua que houve login apenas porque a tela aceitou o código.
• Se houver um novo envio, trate-o como uma tentativa distinta e confira na documentação oficial como o fluxo lida com códigos anteriores. Não presuma prazo de validade, expiração ou substituição sem confirmação para a versão em teste.
• Remova as credenciais, as mensagens e os dados da execução quando já não forem necessários para a investigação.

Se o endereço de teste não receber a mensagem, confira primeiro se a aplicação chegou à etapa de envio e se existe evidência no capturador ou nos registros disponíveis. Depois, verifique o acesso à caixa e compare o resultado com as instruções oficiais de autenticação e solução de problemas de dois fatores. Essa documentação orienta a investigação, mas não autoriza concluir que todo endereço é compatível, que a entrega deve ocorrer num prazo específico ou que um atraso isolado prova uma falha do GitLab.

Ao comparar uma caixa controlada com a captura local, mantenha o objetivo explícito. A primeira é adequada para verificar recebimento numa caixa acessível à equipe; a segunda ajuda a inspecionar o conteúdo produzido durante o desenvolvimento. Nenhuma substitui a confirmação da sessão autenticada quando o critério é validar o login completo.

Segurança e publicação: preserve evidências sem ampliar o risco

A equipe responsável pela liberação deve conseguir reconstruir o que foi testado sem reutilizar o segredo. Registre a versão e o tipo de instalação, as configurações relevantes, o ambiente de captura ou recebimento, o resultado da submissão e a confirmação da sessão. Descreva a evidência de modo que fique claro se o teste validou somente o conteúdo, o recebimento ou o fluxo completo.

O relatório também deve explicitar o que o ensaio não prova. Um resultado numa instância Self-Managed não demonstra a política do GitLab.com; um resultado local no GDK não garante o comportamento de uma instalação externa; uma caixa de teste não comprova a compatibilidade de todos os provedores. Essas limitações fazem parte do resultado e devem acompanhar a aprovação.

Não use endereço temporário em contas de produção, contas administrativas ou serviços dos quais a equipe dependa para recuperar acesso. Uma conta importante precisa de um endereço duradouro sob controle da organização e de métodos de recuperação compatíveis com as regras internas. Para reduzir a exposição de dados em testes, consulte também as orientações de privacidade no uso de caixas de e-mail.

Por fim, remova as credenciais e as mensagens de teste conforme a política de retenção da equipe. O código recebido é um segredo de autenticação, mesmo quando a conta é descartável. Evite deixá-lo em registros de CI, artefatos acessíveis a toda a equipe ou capturas que sobrevivam à necessidade do teste. Para escolher entre uma caixa temporária e uma caixa secundária duradoura, considere se a conta precisará receber mensagens de recuperação no futuro; o guia sobre caixa temporária ou caixa secundária ajuda a separar esses usos.

A aprovação também deve estar vinculada ao ambiente realmente observado. Se uma equipe atualizar o GitLab ou alterar as configurações relacionadas, repita a validação pertinente: uma evidência antiga não confirma o comportamento da versão atual. Quando a documentação oficial modificar as orientações de Email OTP, rollout, autenticação ou testes, revise o roteiro e os critérios de aceitação usados pela equipe.

Perguntas frequentes

Como preparar um ambiente isolado para testar o Email OTP no GitLab?
Use uma instância sob controle da equipe, uma conta não produtiva e um endereço de recebimento autorizado. Registre a versão e as configurações antes do ensaio. Defina se a aprovação exige geração, recebimento ou login completo: capturar uma mensagem localmente não demonstra, por si só, entrega externa nem criação de sessão.

Como habilitar e validar o OTP por e-mail no GitLab Self-Managed?
Não aplique automaticamente as regras do GitLab.com. Confira a documentação correspondente à versão instalada, identifique as opções disponíveis na instância e registre os valores efetivos. Em seguida, faça login com uma conta isolada, verifique se o fluxo pede o código e confirme que a submissão termina numa sessão autenticada.

Como saber se o login passou depois de capturar o código localmente?
A captura confirma que a aplicação encaminhou uma mensagem ao coletor, não que uma caixa externa a recebeu. Registre separadamente a mensagem, a resposta ao enviar o código e o estado final da sessão. Para comprovar recebimento real, use uma caixa controlada pela equipe e confira nela a mensagem da tentativa.

O que verificar se o endereço de teste não recebe o código do GitLab?
Confira se o fluxo chegou à etapa de envio, se existe mensagem no capturador ou evidência nos registros permitidos e se a caixa controlada está acessível. Depois, consulte as instruções oficiais de autenticação e solução de problemas. Não presuma prazo de entrega, validade específica do código ou compatibilidade universal do endereço.

Para uma validação de QA que precisa comprovar recebimento controlado, um endereço temporário pode ser uma opção, desde que a instância e a conta sejam de teste e que a política da equipe permita. Antes de usá-lo, confira as capacidades e os limites do serviço na página de acesso do CloneInbox. Essa escolha não se aplica a contas importantes: para elas, mantenha um endereço duradouro, controlado e adequado à recuperação de acesso.

Perguntas frequentes