Inscription de compte simplifiée avec des codes par e-mail

[rishabh]

Les communautés Discourse peuvent désormais permettre aux utilisateurs de se connecter à l’aide d’un court code envoyé par e-mail plutôt que d’un lien magique, offrant ainsi un flux de connexion sans mot de passe qui semble familier à de nombreuses autres plateformes SaaS et qui fonctionne en complément de votre configuration de second facteur existante.

Dans ce sujet, nous passerons en revue les principaux changements et partagerons comment vous pouvez 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 lorsque le dernier chiffre est rempli.
3. S’ils ont activé l’authentification à deux facteurs (TOTP, codes de secours ou clé de sécurité), l’étape standard de 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 l’instant, cela est considéré comme un changement expérimental ! Avant de le déployer plus largement, nous accueillons vos commentaires pour nous aider à apporter des améliorations.

Pour l’activer, rendez-vous sur la page Changements à venir dans votre zone d’administration (/admin/config/upcoming-changes) et recherchez l’élément Activer les connexions locales via code. Mettez à jour le champ Activé pour… pour inscrire votre site à ce nouveau design :

Avant d’activer, confirmez que enable_local_logins et enable_local_logins_via_email sont également définis 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 le changement activé, le chemin de connexion par code apparaît automatiquement.

Qu’en pensez-vous ?

C’est à vous : nous aimerions beaucoup savoir ce que vous pensez de cette nouvelle fonctionnalité. Ce que vous aimez et n’aimez pas ; ce qui fonctionne bien, et ce qui pourrait être amélioré ?

[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)