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 :
Ils saisissent une adresse e-mail et cliquent sur Continuer.
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.
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é ?
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.
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.
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é.
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.
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).
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.)
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 ».
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 ?
Ce qui a changé
Activer les codes de connexion à usage unique dans votre communauté
Avant d’activer, confirmez que 
Qu’en pensez-vous ?
