As comunidades 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 parece familiar para muitas outras plataformas SaaS e funciona junto com sua configuração existente de segundo fator.
Neste tópico, revisaremos as principais mudanças e compartilharemos como você pode começar a usar isso hoje.
O que mudou
Quando esse recurso é ativado, os membros veem um fluxo mais simples:
Eles inserem um endereço de e-mail e clicam em Continuar.
Um código de seis dígitos chega à sua caixa de entrada. Eles colam (ou digitam) e o formulário é enviado automaticamente quando o último dígito é preenchido.
Se eles tiverem a autenticação de dois fatores habilitada (TOTP, códigos de backup ou chave de segurança), a etapa padrão de 2FA aparecerá 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 só podem ser resgatados uma vez.
Ativando códigos de login de uso único em sua comunidade
Por enquanto, isso é considerado uma mudança experimental! Antes de implantá-la mais amplamente, estamos recebendo seus comentários para nos ajudar a fazer melhorias.
Para ativá-lo, vá para a página Mudanças futuras em sua área de administração (/admin/config/upcoming-changes) e encontre o item Ativar logins locais via código. Atualize o campo Ativado para… para optar seu site por este novo design:
Antes de ativar, confirme que tanto enable_local_logins quanto enable_local_logins_via_email também são true, pois o recurso não pode ser ativado sem eles. Se você estiver usando DiscourseConnect (enable_discourse_connect), esse recurso não pode ser ativado.
Assim que a mudança for ativada, o caminho de login por código aparecerá automaticamente.
O que você acha?
Agora é com você: adoraríamos saber o que você acha deste novo recurso. O que você gosta e não gosta; o que está funcionando bem e o que poderia ser melhorado?
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.
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.
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.
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.
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).
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.)
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”.
O que mudou
Ativando códigos de login de uso único em sua comunidade
Antes de ativar, confirme que tanto 
O que você acha?
