Development #72440
authn mobile : XOR sur le username/email et le numéro de téléphone
0%
Description
Dans #69222 j’imaginais en front un sélecteur qui fait apparaître l’un ou l’autre des deux champs (et qui sans doute vide le contenu du champ qui disparaît), mais l’idée ne fait pas trop d’adepte sur le salon tech.
En l’état, c’est le champ username/email qui a la précédence sur le champ phone, ce dernier est ignoré si username/email est fourni.
Garder ces deux champs affichés en simultanés et ce comportement en l’état c’est prendre le risque de perdre des usagers, qui par exemple pourraient croire qu’il faut fournir username/email et un numéro de téléphone pour parvenir à s’authentifier dans Publik.
Je serais pour afficher une erreur de validation du formulaire d’authentification si les deux champs sont saisis par l’usager.
Demandes liées
Historique
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #69221: backend authn : faire que le backend login/mot de passe accepte le numéro de téléphone de l’usager ajouté
Mis à jour par Frédéric Péters il y a plus d'un an
Pourquoi pas un unique champ ? (ça ne détonnerait pas : le champ actuel est à la fois "identifiant" et "courriel").
Et j'imagine "les gens" habitués à ça vu que c'est ainsi chez les GAFAM.
Mis à jour par Paul Marillonnet il y a plus d'un an
Frédéric Péters a écrit :
Pourquoi pas un unique champ ? (ça ne détonnerait pas : le champ actuel est à la fois "identifiant" et "courriel").
Et j'imagine "les gens" habitués à ça vu que c'est ainsi chez les GAFAM.
Actuellement c’est deux champs différents car on gère le souci d’ambiguïté des numéros locaux en présentant à l’usager un sélecteur "région (indicatif)".
Google, Amazon, et Microsoft arrivent à faire sans, c’est vrai, je ne sais pas comment ils gèrent cette ambiguïté (j’imagine que ça doit juste pas marcher pour certains usagers dont le numéro local est déjà connu du service dans une autre région…).
Chez Apple on se connecte carrément avec un ID opaque délivré à l’enregistrement et rien d’autre, par contre sur la page d’enregistrement le champ numéro de téléphone est à part et présente bien la liste de sélection de l’indicatif : https://appleid.apple.com/account
Chez AirBnb, “GAFAM d’honneur”, c’est bien deux champs séparés avec un sélecteur (qui présente par défaut le tél) avec toujours la sélection de l’indicatif dans une liste avant de saisir le numéro local : https://www.airbnb.fr/login
Mis à jour par Paul Marillonnet il y a plus d'un an
Paul Marillonnet a écrit :
Actuellement c’est deux champs différents car on gère le souci d’ambiguïté des numéros locaux en présentant à l’usager un sélecteur "région (indicatif)".
Google, Amazon, et Microsoft arrivent à faire sans, c’est vrai, je ne sais pas comment ils gèrent cette ambiguïté (j’imagine que ça doit juste pas marcher pour certains usagers dont le numéro local est déjà connu du service dans une autre région…).
Ah, le fait que Google présente le même sélecteur de région, à l’enregistrement du compte seulement, laisse croire qu’ensuite à la connexion il y a une tentative de résolution en numéro global sans que l’usager puisse choisir la région depuis laquelle le numéro local doit être composable. Pas sûr du tout qu’on veuille aller vers ça.
Mis à jour par Benjamin Dauvergne il y a plus d'un an
Dans mon idée 99% des numéros seront des numéros locaux, pour la plupart des pays ça veut dire un seul indicatif, mais pour la France on en aura plusieurs pour les DOM/TOM, pas bien grave.
Les gens rentreront leur numéro au format local dans la plupart des cas. Le formulaire de login devrait normaliser ce numéro au format international pour tous les indicatifs locaux et chercher ça. Si le numéro est déjà au format international, on reste comme ça. Si notre page d'enregistrement est bien faite et qu'on enregistre le numéro avec le mot de passe lors de la définition du mot de passe, tout ira bien (il faudrait peut-être rappeler email/tél en champ readonly sur la page de pose du mot de passe pour que le navigateur puisse l'enregistrer, je n'ai jamais vérifié si ça marchait bien actuellement).
Mis à jour par Paul Marillonnet il y a plus d'un an
Ok donc plutôt garder ce PhoneField(MultiValueField) pour l’écran d’enregistrement uniquement et faire un seul champ pour la page de connexion. Je vais faire un ticket.
Mis à jour par Paul Marillonnet il y a plus d'un an
- Lié à Development #72449: authn mobile : conserver le PhoneField custom pour l’enregistrement uniquement, basculer sur un unique champ username/email/tél pour la page de connexion ajouté