Inscription plus simple avec des codes par e-mail

[rishabh]

Les communautés Discourse peuvent désormais permettre aux utilisateurs de se connecter à l’aide d’un code court envoyé par e-mail, plutôt que par un lien magique. Cette approche de connexion sans mot de passe, familière à de nombreuses autres plateformes SaaS, fonctionne en parallèle avec votre configuration existante de double authentification.

Dans ce sujet, nous passerons en revue les principaux changements et vous expliquerons comment commencer à l’utiliser dès aujourd’hui.

Ce qui a changé

Lorsque cette fonctionnalité est activée, les membres voient un flux plus simple :

:

1. Ils saisissent une adresse e-mail et cliquent sur Continuer.
2. Un code à six chiffres arrive dans leur boîte de réception. Ils le collent (ou le saisissent) et le formulaire se soumet automatiquement dès que le dernier chiffre est rempli.
3. S’ils ont activé la double authentification (TOTP, codes de secours ou clé de sécurité), l’étape standard de la 2FA apparaît ensuite.

Quelques détails à connaître : les codes sont valides pendant 10 minutes, expirent après 5 tentatives échouées et ne peuvent être utilisés qu’une seule fois.

Activer les codes de connexion à usage unique dans votre communauté

Pour le moment, cela est considéré comme une modification expérimentale ! Avant de la déployer plus largement, nous accueillons vos retours pour nous aider à effectuer des améliorations.

Pour l’activer, rendez-vous sur la page Modifications à venir dans votre espace d’administration (/admin/config/upcoming-changes) et trouvez l’élément Activer les connexions locales via code. Mettez à jour le champ Activé pour… pour inscrire votre site à cette nouvelle conception :

Avant d’activer, confirmez que enable_local_logins et enable_local_logins_via_email sont également sur true, car la fonctionnalité ne peut pas être activée sans eux. Si vous utilisez DiscourseConnect (enable_discourse_connect), cette fonctionnalité ne peut pas être activée.

Une fois la modification activée, le chemin de connexion par code apparaît automatiquement.

Noms d’utilisateur aléatoires pour les nouveaux comptes

Les nouveaux membres qui s’inscrivent sans nom d’utilisateur reconnaissable dans leur e-mail se voient désormais attribuer un nom généré convivial, comme « QuietFalcon42 », au lieu d’un espace réservé générique comme user1. L’étape de préparation du compte préremplit la suggestion et inclut un bouton de dé à jouer pour en générer un nouveau.

Les listes de mots derrière les suggestions sont configurables via les paramètres de site random_username_adjectives et random_username_nouns, permettant aux communautés de les adapter à leur ton ou à leur langue. Pour opter pour l’ancienne solution de repli numérotée, désactivez enable_random_usernames.

Qu’en pensez-vous ?

À vous : nous serions ravis de connaître votre avis sur cette nouvelle fonctionnalité. Que vous plaît-il et qu’est-ce qui vous déplaît ? Que fonctionne bien et que pourrait-on améliorer ?

[darkpixlz (Pyx)]

Je viens de tester cela sur mon site. Je ne sais pas ce que pensent les autres, mais cela me semble être une régression assez importante en tant qu’utilisateur de gestionnaire de mots de passe…

Ce nouveau flux supprime la stratégie actuelle « générer l’e-mail, saisir le nom d’utilisateur, générer le mot de passe, sauvegarder » que mon gestionnaire de mots de passe m’a incité à adopter, et vous oblige à saisir l’e-mail en premier avant tout le reste. Je n’ai aucun problème avec le système de code par e-mail (et je le préfère presque, surtout si le code est inclus dans l’objet du mail), mais je m’oppose fermement à la suppression des autres champs de données du compte. Si j’étais un utilisateur sans aucune compétence technique, je comprendrais parfaitement que je n’envoie pas mon adresse e-mail dans une case sans aucune information, car ce n’est pas un design courant. Avant que cela ne devienne définitif, ce serait génial si ces champs étaient rétablis.

[dfabulich (Dan Fabulich)]

Les codes par e-mail, aka les « magic links », sont corrects, mais inciter les utilisateurs à utiliser des passkeys rend l’expérience bien, bien meilleure.

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

L’un des plus gros problèmes avec les codes par e-mail est qu’ils ne font pas ce que vous voudriez qu’ils fassent dans les navigateurs intégrés aux applications, y compris celui de Gmail.

Le problème le plus courant que les gens rencontrent avec les magic links est qu’ils pensent avoir connecté au site sur leur navigateur habituel, mais ils sont en réalité connectés via un navigateur intégré à une application. Par exemple, quelqu’un pourrait recevoir le lien de connexion dans son e-mail. Il ouvre l’application Gmail, clique sur le bouton « Se connecter à 404 Media », et son téléphone charge la page web. Mais cela charge le site dans le navigateur web de Gmail, et non dans votre Safari natif.

Les passkeys résolvent ce problème.

Pour commencer, les sites web utilisant des magic links peuvent proposer les passkeys comme une fonctionnalité optionnelle, à opt-in, pour les clients qui se sont plaints de la façon dont leurs magic links fonctionnent actuellement. Pour s’assurer qu’aucun problème ne survienne, en guise de lancement progressif, ils pourraient rendre cette fonctionnalité entièrement opt-in.

Un peu plus tard, une fois que les personnes gérant le site web sont convaincues que les passkeys aident vraiment à résoudre les problèmes d’expérience utilisateur liés aux magic links, elles peuvent inciter les utilisateurs à ajouter des passkeys après s’être connectés, tous les 90 jours environ, ou chaque fois qu’ils utilisent la fonction de connexion multi-appareils des passkeys. La formulation d’une telle incitation pourrait être quelque chose comme ceci pour les utilisateurs d’appareils Apple : Vous souhaitez éviter de devoir vérifier vos e-mails la prochaine fois ? Configurez une passkey pour utiliser Face ID ou Touch ID afin de vous connecter rapidement et en toute sécurité.

Inciter les utilisateurs à utiliser des passkeys revient à les inciter à utiliser un gestionnaire de mots de passe, car les passkeys ne sont rien d’autre que des mots de passe qui nécessitent un gestionnaire de mots de passe.

[Don]

Bonjour

J’aime beaucoup cette approche ! Cependant, le fait que le nom affiché ne puisse pas être modifié avant la fin de l’inscription me dérange un peu. Je pense qu’il serait excellent d’ajouter une option pour le modifier au cours du processus.

Dans ma communauté, j’ai désactivé le paramètre de site Prioritize username in UX, ce qui signifie que le nom complet/nom affiché est privilégié dans toute l’interface. En raison de cela, les noms attribués automatiquement comme « user21 » ont l’air assez mauvais sur le front-end si l’utilisateur n’a pas d’option immédiate pour les personnaliser.

Merci !

[pmusaraj (Penar Musaraj)]

@dfabulich

L’un des plus grands problèmes avec les codes par e-mail est qu’ils ne fonctionnent pas comme on le souhaiterait dans les navigateurs intégrés aux applications, y compris celui de Gmail.

Ce nouveau flux n’envoie pas de lien magique. Il envoie uniquement le code. L’utilisateur reste sur la même page et copie/colle le code depuis son e-mail vers le formulaire d’inscription. Cette nouvelle approche aide donc avec les navigateurs intégrés aux applications (c’est l’un des principaux avantages de ce changement).

@dfabulich

Orienter les utilisateurs vers les clés de passage

C’est certainement quelque chose que nous aimerions faire ensuite, à l’étape du mot de passe de l’inscription. Les applications et les sites web ont accru leur prise en charge des clés de passage, je vois constamment l’incitation aux clés de passage dans de nombreux contextes, il est donc logique de l’ajouter à Discourse également. (Une masse critique de prise en charge est très utile dans ce passage des mots de passe aux clés de passage.)

[DomMcD (Dominic McDevitt)]

Mon seul problème avec cette fonctionnalité est qu’elle supprime les champs « nom » et « nom d’utilisateur » de ma page d’inscription. Est-ce intentionnel ? Je ne veux pas obliger les utilisateurs à fouiller dans les paramètres juste après l’inscription pour définir un nom d’utilisateur autre que « user63 ».

[kddkd (16)]

Cette méthode d’inscription par code de vérification par e-mail est exactement le changement que je souhaitais depuis longtemps !

[Moin]

Sans cette modification, le lien « J’ai oublié mon mot de passe » et le lien « Envoyez-moi un e-mail » avaient la même taille. Maintenant, ce dernier est plus grand. Est-ce intentionnel ?

[Moin]

Le problème a été corrigé dans

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

[rishabh]

Merci pour vos retours, oui, c’est intentionnel dans le cadre d’une méthode plus rapide pour créer des comptes.

@DomMcD

Je ne veux pas obliger les utilisateurs à fouiller dans les paramètres juste après l’inscription, simplement pour définir un nom d’utilisateur qui ne soit pas « user63 ».

Bien noté. Nous explorons effectivement des idées pour simplifier cette étape suivante ou pour attribuer les noms d’utilisateur initiaux selon une autre méthode.

[Moin]

Je suis d’accord. Ces noms d’utilisateur génériques rendent l’interaction avec les utilisateurs plus confuse. Comme les utilisateurs ont par défaut seulement trois jours pour mettre à jour leurs noms, je m’attends à ce qu’ils s’en rendent souvent compte une fois ce délai écoulé, ce qui oblige le personnel à se charger de les renommer.
J’ai vraiment apprécié que Offering blank username suggestions rather than ‘UserN’ at signup empêche cela de se produire, par exemple ici sur meta. Le dernier utilisateur userXXX a été créé le 7 janvier, avant que cette correction ne soit fusionnée. Ensuite, il n’y a eu aucun nouveau userXXX jusqu’à ce que cette fonctionnalité soit activée, et depuis, il y en a douze de nouveaux.

[Thomas_Rother (Thommie Rother)]

Cette fonctionnalité est extrêmement utile. De plus en plus de plateformes utilisent la fonction « code à usage unique par e-mail » pour proposer des connexions sécurisées avec une authentification à plusieurs facteurs (MFA), sans avoir besoin d’avoir un appareil spécifique (avec l’authentificateur approprié) sous la main.

[rishabh]

@DomMcD

Je ne veux pas obliger les utilisateurs à fouiller dans les paramètres juste après l’inscription, uniquement pour choisir un nom d’utilisateur qui ne soit pas « user63 ».

@Moin

Je suis d’accord. Ces noms d’utilisateur génériques rendent les interactions avec les utilisateurs plus confuses. Comme les utilisateurs ne disposent par défaut que de 3 jours pour mettre à jour leur nom, je suppose qu’ils s’en apercevront souvent après l’expiration de ce délai, ce qui obligera le personnel à s’occuper du renommage.

Vous ne voyez pas cette étape lors de la création du compte ?

[Moin]

C’est une citation étrange : il semble que DomMcD m’ait cité, ce qui n’est pas le cas.

Je n’ai pas testé les étapes. Je commentais ce que j’avais remarqué concernant les nouveaux utilisateurs ici sur Meta. Peu importe si je vois un champ lors de l’inscription. Je dois composer avec ce que les autres font avec ce champ.

Je me demande aussi comment les noms sont gérés. Bien que tous les utilisateurs ne semblent pas utiliser les noms d’utilisateur générés, je remarque même plus ceux qui ont un nom de la forme userXXX.

Ils semblent obtenir cela même en changeant le nom d’utilisateur, et cela entraîne l’utilisation répétée du même numéro jusqu’à ce que le nom d’utilisateur soit déjà pris, puis cela recommence avec le numéro suivant.

Par exemple, 0102100988082, mohamedasarudeen et user603 ont tous « user603 » comme nom.

Je sais qu’ils pourraient changer leur nom, mais encore une fois, je ne peux pas modifier mon expérience lors de l’interaction avec eux.

[rishabh]

Merci à tous pour vos retours, un correctif sera fusionné très bientôt :

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

[rishabh]

Mise à jour

Grâce au dernier travail de @keegan, nous disposons désormais d’une fonctionnalité de génération de noms d’utilisateur à cette étape, qui préremplit une suggestion :

@rishabh

Noms d’utilisateur aléatoires pour les nouveaux comptes

Les nouveaux membres qui s’inscrivent sans nom d’utilisateur reconnaissable dans leur adresse e-mail reçoivent désormais un nom généré amical, comme « QuietFalcon42 », au lieu d’un espace réservé générique comme user1. L’étape de finalisation du compte préremplit la suggestion et inclut un bouton de dé à coudre pour en générer un nouveau.

Les listes de mots derrière les suggestions sont configurables via les paramètres du site random_username_adjectives et random_username_nouns, permettant aux communautés de les adapter à leur ton ou à leur langue. Pour désactiver cette fonction et conserver l’ancienne solution de repli numérotée, désactivez enable_random_usernames.

[Jagster (Jakke Flemming)]

Une demande un peu orientée UX, si c’est possible. Celle-ci :

Mes appareils sont sûrs qu’il faut un mot de passe ici, mais il devrait demander l’adresse e-mail. Ensuite, mes téléphones et autres appareils sauraient qu’il faut proposer une adresse plutôt que d’autres identifiants.