Project

General

Profile

Development #72440

authn mobile : XOR sur le username/email et le numéro de téléphone

Added by Paul Marillonnet over 1 year ago. Updated over 1 year ago.

Status:
Nouveau
Priority:
Normal
Category:
-
Target version:
-
Start date:
14 December 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

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.


Related issues

Related to Authentic 2 - Development #69221: backend authn : faire que le backend login/mot de passe accepte le numéro de téléphone de l’usagerFermé19 September 2022

Actions
Related to Authentic 2 - 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 connexionFermé15 December 2022

Actions

History

#1

Updated by Paul Marillonnet over 1 year ago

  • Related to Development #69221: backend authn : faire que le backend login/mot de passe accepte le numéro de téléphone de l’usager added
#2

Updated by Paul Marillonnet over 1 year ago

  • Assignee set to Paul Marillonnet
#3

Updated by Frédéric Péters over 1 year ago

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.

#4

Updated by Paul Marillonnet over 1 year ago

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

#5

Updated by Paul Marillonnet over 1 year ago

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.

#6

Updated by Benjamin Dauvergne over 1 year ago

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

#7

Updated by Paul Marillonnet over 1 year ago

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.

#8

Updated by Paul Marillonnet over 1 year ago

  • Related to 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 added

Also available in: Atom PDF