auth.users
O usuário autenticado agindo sobre o próprio perfil e as próprias identidades.
Tudo aqui age como o usuário atual, sobre ele mesmo. Para agir sobre outras
pessoas, isso é o auth.admin.users, que
precisa de chave secreta e vive no servidor.
Cinco destes exigem chave secreta
update, sendOTPToUpdateEmail, confirmEmailUpdate, sendOTPToUpdatePhone e
confirmPhoneUpdate são alcançáveis apenas com sk- — chamados de um client
de navegador, a requisição é recusada antes de chegar ao seu código. Todo o
resto aqui, incluindo o me e toda a superfície de identities, funciona com
qualquer uma das duas chaves.
A regra por trás disso: um endpoint que não declara quais tipos de chave aceita cai no padrão de só-secreta. Então a divisão não é arbitrária — substituir uma credencial principal é do servidor, enquanto adicionar uma identidade ao lado de outra já existente não é.
A distinção que atravessa esta página: um usuário é uma pessoa com um id, e uma identidade é uma forma de provar que ela é essa pessoa. Um usuário com senha, login do Google e um e-mail de trabalho tem um id e três identidades — e é por isso que entrar com Google depois de ter se cadastrado por e-mail não cria uma segunda conta.
me
me() → User
O perfil completo de quem estiver autenticado.
const { data: user } = await nulvless.auth.users.me();idstringRequiredEstável pela vida da conta, através de toda identidade adicionada depois.
emailstringOptionalO e-mail principal. A lista completa está em identities.
phonePhoneOptionalusernamestringOptionalprofileUserProfileOptionalname, biography, gender, avatar_uri, date_of_birth.
identitiesIdentity[]OptionalTodas as formas pelas quais esta pessoa consegue entrar.
metadataRecord<string, string | number>OptionalDados seus. Só um admin pode definir.
is_confirmedbooleanOptionalCom confirmed_at.
is_bannedbooleanOptionalCom banned_at. Um usuário banido não consegue entrar, mas o registro e o
histórico dele sobrevivem.
password_enabledbooleanOptionalSe o usuário tem senha, independentemente dos métodos de entrada habilitados na plataforma. Use para oferecer "Definir senha" ou "Alterar senha".
last_sign_in_atstringOptionalupdate
update(params) → User
Atualiza o próprio perfil do usuário autenticado. Campos omitidos ficam como estão.
const { data: user } = await nulvless.auth.users.update({
profile: { name: 'Ada Lovelace', biography: 'Máquinas analíticas.' },
});usernamestringOptionalSujeito às mesmas regras do cadastro, e ainda precisa ser único.
profileUserProfileOptionalname, biography, gender, avatar_uri, date_of_birth.
Identidades estão deliberadamente ausentes. Um e-mail ou telefone nunca é editado no lugar — você adiciona o novo e confirma, que é sobre o que trata o resto desta página.
getIdentities
getIdentities(type?) → Identity[]
Tudo que está ligado à conta.
const { data: identities } = await nulvless.auth.users.getIdentities();
const { data: emails } = await nulvless.auth.users.getIdentities('email');typeIdentityTypeOptionalEstreita o resultado.
emailEndereços de e-mail.phoneNúmeros de telefone.oauthProvedores sociais, cada um com provider e provider_id.Cada identidade carrega um id — que é o que updateIdentity e
removeIdentity recebem — mais identifier (o endereço, número ou conta do
provedor) e created_at.
Esta é a tela de "contas e endereços conectados".
addEmailIdentity
addEmailIdentity({ email, nonce }) → Challenge
Começa a adicionar um segundo e-mail à conta. Um código é enviado para o endereço novo.
const { data: challenge } = await nulvless.auth.users.addEmailIdentity({
email: '[email protected]',
nonce: code,
});emailstringRequiredO endereço sendo adicionado.
noncestringOptionalConfirmação de sudo. Veja abaixo.
Devolve um Challenge — nada foi adicionado ainda. Finalize com
verifyIdentity.
Exige sudo
Protegido sob manage_identities. Adicionar um endereço que você controla à
conta de outra pessoa é um sequestro de conta, então uma sessão roubada não pode
conseguir fazer isso em silêncio.
addPhoneIdentity
addPhoneIdentity({ phone, nonce }) → Challenge
O mesmo fluxo para um número de telefone.
await nulvless.auth.users.addPhoneIdentity({
phone: { country_code: '+55', number: '11987654321' },
nonce: code,
});phonePhoneRequired{ country_code, number }.
noncestringOptionalverifyIdentity
verifyIdentity({ token, code }) → User
Confirma uma adição iniciada por qualquer uma das duas chamadas acima.
const { data: user } = await nulvless.auth.users.verifyIdentity({
token: challenge.token,
code,
});tokenstringRequiredVindo do desafio que você recebeu.
codestringRequiredO que a pessoa recebeu no novo endereço ou número.
Devolve o User atualizado, com a nova identidade presente. Até isso dar certo,
o endereço não está anexado e não pode ser usado para entrar.
updateIdentity
updateIdentity({ id, primary, nonce }) → User
Muda qual identidade é a principal.
await nulvless.auth.users.updateIdentity({ id, primary: true, nonce: code });idstringRequiredVindo do getIdentities().
primarybooleanRequiredA única propriedade que pode ser mudada hoje. Um identificador nunca é editado no lugar — você adiciona o novo e remove o antigo.
noncestringOptionalExige sudo
manage_identities.
removeIdentity
removeIdentity({ id, nonce }) → Identity
Desvincula uma identidade. Devolve a que foi removida.
const { data: removed } = await nulvless.auth.users.removeIdentity({
id,
nonce: code,
});idstringRequirednoncestringOptionalRemover a última identidade capaz de entrar tranca a conta do lado de fora. A plataforma não decide por você quais combinações deixam uma conta utilizável, então verifique antes de oferecer o botão — quem só tem uma identidade do Google e a desvincula fica sem nada.
sendOTPToUpdateEmail
sendOTPToUpdateEmail({ email, nonce }) → Challenge
Começa a substituir o e-mail principal, em vez de adicionar outro.
const { data: challenge } = await nulvless.auth.users.sendOTPToUpdateEmail({
email: '[email protected]',
nonce: code,
});emailstringRequiredO novo endereço. O código vai para lá, que é o que prova que a pessoa o controla.
noncestringOptionalFinalize com confirmEmailUpdate.
Exige sudo
manage_credentials — um grupo diferente do de adicionar identidade, e um
ambiente pode exigir um sem exigir o outro.
confirmEmailUpdate
confirmEmailUpdate({ token, code }) → User
Completa a mudança. Devolve o User atualizado.
const { data: user } = await nulvless.auth.users.confirmEmailUpdate({
token: challenge.token,
code,
});O endereço antigo deixa de ser o principal neste ponto. Se ele permanece como
identidade secundária depende de como foi anexado inicialmente — leia
identities da resposta em vez de supor.
sendOTPToUpdatePhone
sendOTPToUpdatePhone({ phone, nonce }) → Challenge
O mesmo fluxo de substituição para o número de telefone.
await nulvless.auth.users.sendOTPToUpdatePhone({
phone: { country_code: '+55', number: '11987654321' },
nonce: code,
});confirmPhoneUpdate
confirmPhoneUpdate({ token, code }) → User
Completa, devolvendo o User atualizado.
await nulvless.auth.users.confirmPhoneUpdate({ token: challenge.token, code });Adicionar ou substituir?
Os dois pares se parecem e não são intercambiáveis:
addEmailIdentity→verifyIdentitymantém o endereço existente no lugar e dá à pessoa uma segunda forma de entrar. Grupo de sudomanage_identities, e chamável com qualquer uma das chaves.sendOTPToUpdateEmail→confirmEmailUpdatetroca o endereço principal. Grupo de sudomanage_credentials, e só com chave secreta — esse par não roda no navegador, então a troca precisa passar pelo seu próprio servidor.
Os dois enviam um código para o endereço novo, e nenhum muda nada antes desse código voltar.