Cadastro de conta mais fácil com códigos por e-mail

[rishabh]

As comunidades do Discourse agora podem permitir que os usuários façam login usando um código curto enviado por e-mail, em vez de um link mágico, oferecendo um fluxo de login sem senha que é familiar para muitas outras plataformas SaaS e que funciona em conjunto com sua configuração existente de segundo fator.

Neste tópico, revisaremos as principais alterações e mostraremos como você pode começar a usar isso hoje.

O que mudou

Quando esse recurso é ativado, os membros veem um fluxo mais simples:

:

1. Eles inserem um endereço de e-mail e clicam em Continuar.
2. Um código de seis dígitos chega à caixa de entrada deles. Eles colam (ou digitam) o código e o formulário é enviado automaticamente quando o último dígito é preenchido.
3. Se eles tiverem a autenticação de segundo fator ativada (TOTP, códigos de backup ou chave de segurança), a etapa padrão de 2FA aparece em seguida.

Alguns detalhes que valem a pena saber: os códigos são válidos por 10 minutos, expiram após 5 tentativas falhas e podem ser resgatados apenas uma vez.

Ativando códigos de login de uso único na sua comunidade

Por enquanto, isso é considerado uma alteração experimental! Antes de implantá-la em larga escala, estamos recebendo seu feedback para nos ajudar a fazer melhorias.

Para ativá-lo, vá para a página Alterações futuras na área administrativa (/admin/config/upcoming-changes) e localize o item Habilitar logins locais via código. Atualize o campo Habilitado para… para que seu site opte por este novo design:

Antes de habilitar, confirme que tanto enable_local_logins quanto enable_local_logins_via_email também estão como true, pois o recurso não pode ser ativado sem eles. Se você estiver usando DiscourseConnect (enable_discourse_connect), este recurso não pode ser habilitado.

Assim que a alteração for habilitada, o caminho de login por código aparecerá automaticamente.

Nomes de usuário aleatórios para novas contas

Novos membros que se inscrevem sem um nome de usuário reconhecível em seu e-mail agora recebem um nome gerado amigável, como “QuietFalcon42”, em vez de um placeholder genérico como user1. A etapa de conta pronta pré-preenche a sugestão e inclui um botão de dado para gerar um novo.

As listas de palavras por trás das sugestões são configuráveis por meio das configurações do site random_username_adjectives e random_username_nouns, permitindo que as comunidades as ajustem ao seu tom ou idioma.

Optando por não gerar nomes de usuário aleatórios

Se você deseja usar códigos de e-mail para inscrição, mas sem a geração de nome de usuário pré-preenchida, clique em Mostrar configurações relacionadas para esta alteração futura e desative a configuração do site enable_random_usernames.

O que você acha?

Agora é com você: gostaríamos de ouvir o que você acha deste novo recurso. O que você gosta e o que não gosta; o que está funcionando bem e o que poderia ser melhorado?

[darkpixlz (Pyx)]

Acabei de testar no meu site. Não sei o que os outros acham, mas, como usuário de gerenciador de senhas, isso parece uma retrocesso bem grande para mim…

Esse novo fluxo remove a estratégia atual de “gerar e-mail, digitar nome de usuário, gerar senha, salvar” em que meu gerenciador de senhas me levou, e obriga você a digitar o e-mail primeiro, antes de tudo. Não tenho problema com a coisa do código de e-mail (e, na verdade, quase prefiro assim, especialmente se o código estiver incluído no assunto do e-mail), mas sou fortemente contra a remoção das outras caixas de dados da conta. Se eu fosse um usuário sem nenhum conhecimento técnico, também não me sentiria à vontade para fornecer meu e-mail em uma caixa sem nenhuma informação, como essa, porque não é um design comum. Antes que isso se torne permanente, seria ótimo se isso fosse adicionado de volta.

[dfabulich (Dan Fabulich)]

Códigos por e-mail, também conhecidos como “links mágicos”, são razoáveis, mas incentivar os usuários a usar chaves de acesso (passkeys) torna a experiência muito, muito melhor.

Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

Um dos maiores problemas com códigos por e-mail é que eles não funcionam como você gostaria em navegadores dentro de aplicativos, incluindo o navegador do Gmail.

Provavelmente, o problema mais comum que as pessoas encontram com links mágicos é acharem que fizeram login no site em seu navegador normal, mas na verdade estão logadas através de um navegador dentro de um aplicativo. Por exemplo, alguém pode receber o link de login por e-mail. Ela abre o aplicativo do Gmail, clica no botão “Entrar no 404 Media” e o celular carrega a página da web. Mas isso está carregando o site no navegador web do Gmail, não no Safari nativo.

Chaves de acesso resolvem esse problema.

Para começar, sites que usam links mágicos podem tornar as chaves de acesso uma função opcional, com adesão voluntária, para os clientes que reclamaram de como seus links mágicos funcionam hoje. Para garantir que isso não cause nenhum problema, como uma espécie de lançamento suave, eles podem tornar a função 100% opcional.

Um pouco depois, quando as pessoas que administram o site estiverem convencidas de que as chaves de acesso realmente ajudam com os problemas de experiência do usuário relacionados aos links mágicos, elas podem incentivar os usuários a adicionar chaves de acesso após o login, a cada 90 dias aproximadamente, ou sempre que fizerem login usando a função de login entre dispositivos das chaves de acesso. A formulação de tal incentivo pode ser algo como isso para usuários de dispositivos Apple: Quer evitar ter que verificar seu e-mail da próxima vez? Configure uma chave de acesso para usar o Face ID ou Touch ID para fazer login rapidamente e com segurança.

Incentivar os usuários a usar chaves de acesso é o mesmo que incentivá-los a usar um gerenciador de senhas, porque as chaves de acesso são apenas senhas que exigem um gerenciador de senhas.

[Don]

Olá

Gosto muito dessa abordagem! No entanto, me incomoda um pouco o fato de o nome de exibição não poder ser alterado antes do final do registro. Acho que seria ótimo adicionar uma opção para alterá-lo durante o processo.

Na minha comunidade, desativei a configuração do site Prioritize username in UX (Priorizar nome de usuário na UX), o que significa que o Nome Completo/Nome de Exibição é priorizado em toda a interface. Por causa disso, nomes atribuídos automaticamente como “user21” ficam com uma aparência bastante ruim na interface frontal se o usuário não tiver uma opção imediata para personalizá-lo.

Obrigado!

[pmusaraj (Penar Musaraj)]

@dfabulich

Um dos maiores problemas com os códigos de e-mail é que eles não fazem o que você gostaria que fizessem em navegadores dentro de aplicativos, incluindo o navegador do Gmail.

Este novo fluxo não envia um link mágico. Ele só envia o código. O usuário permanece na mesma página e copia/cola o código do e-mail para o formulário de registro. Portanto, essa nova abordagem realmente ajuda com navegadores dentro de aplicativos (é uma das principais vantagens da mudança).

@dfabulich

Incentivar os usuários a usarem chaves de passagem

Certamente é algo que gostaríamos de fazer em seguida, na etapa de senha do registro. Aplicativos e sites têm aumentado seu suporte a chaves de passagem, continuo vendo o incentivo para chaves de passagem em muitos contextos, então faz sentido adicionar ao Discourse também. (Uma massa crítica de suporte é muito útil nessa mudança de senhas para chaves de passagem.)

[DomMcD (Dominic McDevitt)]

O meu único problema com este recurso é que ele remove os campos de nome e nome de usuário da minha página de cadastro. Isso é intencional? Não quero obrigar os usuários a vaguearem pelas configurações logo após o cadastro só para definir um nome de usuário que não seja “user63”.

[kddkd (16)]

Este método de registro com código de verificação por e-mail é uma mudança que eu sempre desejei!

[Moin]

Sem essa alteração, o link “Esqueci minha senha” e o link “Enviar por e-mail” tinham o mesmo tamanho. Agora, o último é maior. Isso é intencional?

[Moin]

Foi corrigido em

UX: Match font size of one-time code login link (#41879)

[rishabh]

Obrigado pelo feedback, sim, é intencional como parte de uma maneira mais rápida de criar contas.

@DomMcD

Não quero forçar os usuários a vasculhar as configurações logo após o cadastro só para definir um nome de usuário que não seja “user63”.

Anotado, sim, estamos explorando ideias para tornar essa próxima etapa mais simples ou definir nomes de usuário iniciais usando um método diferente.

[Moin]

Concordo. Esses nomes de usuário genéricos tornam a interação com os usuários mais confusa. Como os usuários, por padrão, têm apenas 3 dias para atualizar os nomes, espero que frequentemente eles percebam isso depois que esse tempo tiver passado, então a equipe precisa cuidar de renomeá-los.
Gostei muito do fato de que Offering blank username suggestions rather than ‘UserN’ at signup impediu que isso acontecesse, por exemplo, aqui no meta. O último usuárioXXX foi criado em 7 de janeiro, antes dessa correção ser integrada. Depois disso, não houve nenhum novo usuárioXXX até que esse recurso fosse ativado, e desde então há 12 novos.

[Thomas_Rother (Thommie Rother)]

Este recurso é extremamente útil. Cada vez mais plataformas estão utilizando a função de ‘código único por e-mail’ para oferecer logins seguros com MFA, sem a necessidade de ter um dispositivo específico (com o autenticador adequado) à mão.

[rishabh]

@DomMcD

Não quero obrigar os usuários a caçarem nas configurações logo após o cadastro, só para definir um nome de usuário que não seja “user63”.

@Moin

Concordo. Esses nomes de usuário genéricos tornam a interação com os usuários mais confusa. Como os usuários, por padrão, têm apenas 3 dias para atualizar os nomes, espero que frequentemente eles percebam isso depois que o tempo tiver passado, de modo que a equipe de suporte precise cuidar da renomeação.

Você não está vendo essa etapa durante a criação da conta?

[Moin]

Esta é uma citação estranha: parece que o DomMcD me citou, o que não é verdade.

Eu não testei os passos. Eu estava comentando sobre o que observei em relação aos novos usuários aqui na Meta. Não importa se eu vejo um campo durante o cadastro. Eu tenho que lidar com o que os outros fazem com esse campo.

Também me pergunto como os nomes são tratados. Embora nem todos os usuários pareçam usar os nomes de usuário gerados, noto que ainda mais deles têm um nome que é userXXX.

Parece que eles recebem isso mesmo ao alterar o nome de usuário, e isso resulta no mesmo número ser usado repetidamente até o nome de usuário ser ocupado, e então recomeça com o próximo número.

Por exemplo, 0102100988082, mohamedasarudeen e user603 todos têm user603 como nome.

Sei que eles poderiam alterar o nome, mas, novamente, eu não posso mudar minha experiência ao interagir com eles.

[rishabh]

Obrigado a todos pelos relatos. Uma correção será integrada em breve:

FIX: Stop placeholder usernames sticking after email code signup (#42796)

[rishabh]

Atualização

Graças ao mais recente trabalho de @keegan, agora temos um recurso de geração de nomes de usuário nesta etapa que preenche automaticamente uma sugestão:

@rishabh

Nomes de usuário aleatórios para novas contas

Novos membros que se inscrevem sem um nome de usuário reconhecível em seu e-mail agora recebem um nome gerado amigável, como “QuietFalcon42”, em vez de um genérico como user1. A etapa de prontidão da conta preenche automaticamente a sugestão e inclui um botão de dado para gerar uma nova.

As listas de palavras por trás das sugestões são configuráveis por meio das configurações do site random_username_adjectives e random_username_nouns, permitindo que as comunidades ajustem o tom ou o idioma. Para desativar e manter o fallback numerado antigo, desative enable_random_usernames.

[Jagster (Jakke Flemming)]

Um pedido meio UX, se possível. Este aqui:

Meus dispositivos estão bem seguros de que preciso de uma senha aqui, mas deveria pedir o e-mail. Assim, meus celulares e outros dispositivos saberiam oferecer um endereço em vez de outras credenciais.

[thisisjoshjones (Joshua Jones)]

Seria possível implementar esse fluxo de cadastro também na página de aterrissagem dos convites? Tenho certeza de que isso está fora do escopo desta fase alfa, mas essa implementação seria muito útil depois que o recurso estiver estável. Isso realmente reduz a barreira de entrada para os membros da minha comunidade, então, obrigada!

[mcwumbly (Dave McClure)]

Por coincidência, há alguns trabalhos em andamento nessa frente aqui:

FEATURE: Use email code for invites (#43138)

[ecki (Bernd)]

Gosto do recurso em geral (primeira etapa de cadastro com apenas e-mail e código), mas ele tem algumas arestas:

a) o login e o cadastro devem ter configurações separadas;
b) ocultar o campo de nome de usuário no formulário de cadastro deve ser uma opção extra, já que os nomes de usuário ainda são um recurso importante de comunicação — nomes aleatórios ou sequenciais parecem bastante estranhos;
c) estranhamente, os nomes de usuário aleatórios funcionaram no meu site para alguns cadastros de spam (entradas de usuários não verificados), mas não para dois usuários reais; ambos receberam “user1” e “user2” como nomes, ugh. (Não tenho certeza qual é a diferença entre os spammers e os usuários);
d) para o login, pode ser um botão extra, talvez um que envie um e-mail com um link mágico e um código. Não vejo a necessidade de separar isso;
e) a documentação deve deixar claro que ela remove o formulário de nome de usuário (ou melhor, não o remover).