Vous êtes sur /login et vous saisissez votre nom d’utilisateur dans le champ « Email/username ». Après la confusion initiale mentionnée ci-dessus, vous cliquez sur « Email me a one-time login code ». Cela vous amène à la page « Welcome back », où le champ « Email » est pré-rempli avec votre nom d’utilisateur (problème n°1). Si vous cliquez distraitement sur « Continue », vous obtenez trois messages rouges d’un coup (problème n°2) :
Incorrect username, email or password
Fix this error to continue - Email - Please enter a valid email address
Please enter a valid email address
Le texte « Login with your password instead » à côté du bouton « Continue » suivant ressemble un peu à une description du bouton Continue, mais ce n’est pas un gros problème.
Ensuite, vous cliquez sur « Continue ». La page passe à l’écran « Welcome back - Check your email », mais l’erreur « Incorrect username, email or password » est toujours présente (problème n°3).
Ici, les liens supplémentaires (« Resend code », « Use a different email address ») se trouvent sous « Continue » et il est plus clair qu’il s’agit d’autre chose.
J’ajoute une note ici pour confirmer qu’à partir de maintenant, la génération de noms d’utilisateur aléatoires n’est pas activée par défaut avec ce changement à venir, et qu’elle est entièrement facultative. Le premier message de ce sujet a été mis à jour en conséquence.
Personnellement, je déteste quand les e-mails de vérification ou de connexion ne contiennent aucun lien à cliquer, donc j’apprécierais que vous ajoutiez une option pour activer ou désactiver ce comportement en tant que préférence du site.
Avoir l’adresse e-mail et le code comme première étape de l’inscription, c’est bien, mais je me demande si c’est acceptable de saisir un e-mail (et d’envoyer un e-mail) sans avoir accepté les conditions de protection des données. Comme déjà mentionné, il faut que cela s’intègre à l’approbation par les modérateurs (c’est-à-dire ne pas envoyer « activez votre compte » si ce n’est pas le cas).
Ce n’est pas une chose facile à mettre en œuvre, pour deux raisons. D’abord, il est préférable que le produit dispose d’un seul mécanisme pour confirmer la propriété d’une adresse e-mail. Avoir deux mécanismes en place est source de confusion pour les utilisateurs finaux, les administrateurs et notre propre équipe de support.
La deuxième raison concerne la sécurité. Un lien peut plus facilement être détourné ou manipulé par un attaquant potentiel. Par exemple, il est facile pour quelqu’un d’envoyer un e-mail qui semble provenir d’un site légitime, avec un lien qui en a l’air tout aussi légitime, mais qui redirige en réalité l’utilisateur vers un autre site ou un autre compte. Les liens facilitent la mise en œuvre d’attaques par ingénierie sociale. Les codes par e-mail, en revanche, non.
Cela devrait être acceptable pour un e-mail ponctuel, non ? Je ne suis pas sûr que cela fasse une différence, qu’on envoie un lien ou un code, dans tous les cas.
Existe-t-il un moyen d’afficher sur cette nouvelle page d’inscription les champs utilisateur personnalisés qui ont l’option « Afficher lors de l’inscription » ou qui sont obligatoires à la création du compte ? Sur notre forum, nous avons des options comme « S’abonner à l’œuvre du mois » qui étaient précédemment proposées aux utilisateurs lors de l’inscription. Bien que cela soit une bonne chose, cela a malheureusement pour effet de contourner la saisie et l’affichage de champs de connexion importants.
En effet, cela ne fonctionne pas non plus pour moi lorsque je définis un code d’invitation.
L’envoi du code par e-mail échoue tout simplement, sans avertissement ni message d’erreur.
J’ai donc dû passer en mode « invitation uniquement ». Mais c’est très bien d’avoir cette méthode d’inscription. Surtout lorsque l’imposition de la double authentification n’est pas une option. C’est assurément plus sûr que de laisser les utilisateurs définir un mot de passe générique qu’ils ont probablement déjà utilisé maintes fois.
Salut, ça semble être une bonne idée, mais cela ajoute un aller-retour supplémentaire d’e-mails.
Nous fonctionnons sur invitation uniquement et envoyons des invitations individuelles par e-mail.
Auparavant, le lien d’inscription par e-mail incluait le jeton étendu, ce qui permettait de s’inscrire sans nécessiter une autre étape de vérification par e-mail.
Avec cette option activée, c’est le jeton court qui est envoyé par e-mail, ce qui nécessite alors un autre aller-retour d’e-mails.
Cela rend le processus d’inscription plus complexe pour les nouveaux utilisateurs.
Oui, ce système n’affiche pas les champs utilisateur sur le formulaire d’inscription, mais il les affiche après la confirmation du code à l’étape suivante.
L’inscription s’est avérée très pratique pour les utilisateurs peu techniques. Il suffit de saisir son adresse e-mail dans la case, d’attendre le code et on est à l’intérieur. Et c’est relativement sécurisé.
Voici quelques points que j’ai remarqués jusqu’à présent :
Le fait que l’utilisation des codes d’invitation soit cassée, comme mentionné précédemment.
Le temps imparti pour saisir les chiffres est très, très court pour les personnes avec qui je travaille, et le code est probablement plus long que nécessaire. À ma connaissance, ni l’un ni l’autre ne sont ajustables, et rien n’indique que cela rende le système plus sûr — seulement plus difficile.
Bien que l’inscription avec simplement une case e-mail soit excellente, il n’a guère de sens que, lors de la prochaine connexion, une case mot de passe apparaisse soudainement, que l’on « doit » renseigner. Comme déjà dit, les utilisateurs avec qui je travaille ne sont pas très techniques ; donc, lorsque l’inscription par code e-mail est le paramètre par défaut, l’apparition d’une case mot de passe (peut-être des semaines plus tard) est source de confusion. La norme attendue de nos jours consiste à avoir uniquement une case e-mail et à laisser le système décider ensuite de demander un mot de passe, un code e-mail ou autre.