Note : il s’agit d’un comportement souhaitable d’un point de vue sécurité, mais nous pouvons améliorer l’expérience utilisateur si cela se produit pour un utilisateur
Si un utilisateur a enregistré un jeton U2F, celui-ci ne fonctionnera pas si le nom d’hôte du site a changé depuis son enregistrement.
Cependant, l’utilisateur ne reçoit aucune indication que cela pourrait être dû à un changement de nom d’hôte, car Discourse ne stocke pas cette information. Si l’utilisateur ne comprend pas pourquoi cela peut se produire, il risque de s’interroger.
Une amélioration possible dans ce cas consisterait à afficher sur cet écran :
Désactiver « S’authentifier avec une clé de sécurité »
Afficher un message du type : « Nous disposons d’une clé de sécurité enregistrée pour ce compte, mais elle ne correspond pas au nom d’hôte de votre requête actuelle (www.example.com) »
Considération :
Si nous procédons ainsi, nous devons veiller à ne pas réaffecter l’ancien nom d’hôte au nouveau dans la table UserSecurityKey
Oui, nous devons ajouter un texte ici @sam pour couvrir le cas du changement de nom de domaine. Je pense que c’est surtout une mise à jour de contenu, comme un avertissement en bas de page ou quelque chose du genre ?
Cela pourrait être un peu délicat, car je pense que le nom d’hôte est stocké à l’intérieur de la clé publique dans la table des clés de sécurité (cela fait un moment que je n’ai pas travaillé là-dessus, donc je pourrais me tromper). Cela nécessitera un peu de manœuvre pour remonter ce problème à l’interface utilisateur afin de désactiver le bouton et afficher le message. De plus, cela ne s’afficherait que si toutes les clés de sécurité enregistrées ont un mauvais nom d’hôte — si l’une d’elles correspond, l’utilisateur n’a pas de problème.
Dans une certaine mesure lié, je dois aussi corriger 2fa security key breaks when migrating to custom domain - #6 by balboah. Je vais m’attribuer ce sujet également, car je pense que lorsque nous changeons de nom d’hôte, nous devrions probablement simplement désactiver toutes les clés de sécurité existantes, car elles deviennent effectivement inutiles.
Je restaure souvent une base de données d’un environnement de production vers un site de staging avec un nom d’hôte différent. Ce serait formidable si cela pouvait, par exemple, désactiver toutes les clés invalides et obliger les administrateurs à les réinitialiser (bien qu’un utilisateur responsable ait déjà des clés de secours configurées, donc cela n’aiderait pas vraiment. ).
).