Cadastro e verificação

O signUp nunca autentica ninguém sozinho. Ele devolve um desafio — o endereço ou telefone precisa ser confirmado antes — e a cara desse desafio depende de como o ambiente está configurado.

O ponto desta página é que você escreve a ramificação uma vez e nunca mais mexe nela quando essa configuração mudar.

const { data, error } = await nulvless.auth.signUp({ email, password });

if (error) return;

if (data.challenge?.preferred === 'link') {
  // Nada a coletar — um link foi enviado por e-mail.
}

if (data.challenge) {
  // Um código foi enviado. Colete.
}

O que decide qual é

Uma configuração do ambiente, Inscrições → Tipo de confirmação:

Uma segunda configuração, Autenticar após inscrição, decide se a conta — uma vez confirmada — também produz uma sessão.

confirmationType: 'otp'

O signUp devolve um desafio com subject: 'sign_up' e preferred como email_otp quando o usuário tem e-mail, sms_otp caso contrário.

const { data } = await nulvless.auth.signUp({ email, password });

if (data.challenge) {
  // Colete o código, e então:
  const { data: done } = await nulvless.auth.verifyChallenge({
    token: data.challenge.token,
    code,
  });
}

Depois de um verifyChallenge bem-sucedido, o authenticateAfterRegistering vale de novo: você recebe uma sessão, ou só o usuário.

confirmationType: 'link'

O desafio volta com preferred: 'link', o que significa que não há nada a coletar. Mostre uma tela de "confira seu e-mail" em vez de um campo de código:

if (data.challenge?.preferred === 'link') {
  setCheckYourEmail(true);
  return;
}

O link cai na URL configurada como confirmAccountLinkUri, carregando um token. A sua página finaliza:

const token = new URLSearchParams(location.search).get('token');
await nulvless.auth.activate(token);

Este caminho exige e-mail — um ambiente em link com cadastro só por telefone é rejeitado.

Um componente para todo código

Como o desafio carrega o subject, a mesma tela serve cadastro, entrada por OTP, MFA e sudo:

function VerifyCode({ challenge }: { challenge: Challenge }) {
  return (
    <form onSubmit={submit}>
      <p>Enviamos um código para {challenge.identifier}</p>
      <input value={code} onChange={(e) => setCode(e.target.value)} inputMode="numeric" />
    </form>
  );
}

challenge.identifier chega mascarado — u***@example.com — então pode ser exibido sem risco. O expires_in está lá para uma contagem regressiva.

O que pode rejeitar um cadastro

Verificado contra as checagens da própria plataforma, na ordem em que rodam:

Cadastros que enviam algo — os caminhos otp e link — também têm limite de taxa, no mesmo balde dos outros envios de verificação.

As regras de senha são do ambiente, não suas

A senha é verificada contra as regras de Senhas: um tamanho mínimo, requisitos de caracteres e, opcionalmente, uma checagem contra senhas sabidamente vazadas. Não reimplemente essas regras no seu formulário — espelhe no texto de ajuda se quiser, mas deixe a plataforma ser quem rejeita, para os dois nunca discordarem.

Escrevendo a ramificação uma vez

O objetivo é justamente que este código sobreviva a um ambiente ser reconfigurado de otp para link e de volta:

const { data, error } = await nulvless.auth.signUp({ email, password, profile });

if (error) return showError(error);

if (data.challenge?.preferred === 'link') return setCheckYourEmail(true);
if (data.challenge) return router.push('/verify', { state: { challenge: data.challenge } });

return router.push('/sign-in');

Três linhas, e nenhuma delas menciona em qual modo o ambiente está.

Próximos