Produits Entr'ouvert » Authentic 2

Ça me parait top, une question : je vois qu'on concatène le phone_prefix et le numéro de téléphone pour construire l'identifiant pour la requête. Ça risque pas de bugger sur des inputs type 0612345678 (avec la concaténation, on aura un +330612345678), à matcher avec potentiellement un +33612345678, sans le zéro ? Il me semble qu'un·e utilisateur aura tendance à taper son numéro avec le 0 comme préfixe mais je peux me tromper.

Plus généralement, peut-être que ça a été déjà discuté ailleurs, comment se passe la normalisation des numéros avant stockage en base ?

À part ces questions, c'est okay pour moi :)

Agate Berriot a écrit :

Ça me parait top, une question : je vois qu'on concatène le phone_prefix et le numéro de téléphone pour construire l'identifiant pour la requête. Ça risque pas de bugger sur des inputs type 0612345678 (avec la concaténation, on aura un +330612345678), à matcher avec potentiellement un +33612345678, sans le zéro ? Il me semble qu'un·e utilisateur aura tendance à taper son numéro avec le 0 comme préfixe mais je peux me tromper.

Agate a raison... bienvenue en enfer, Paul ;)

Je vais ajouter qu'il faut ajouter dans les settings les préfixes des DROM, qui font partie du https://fr.wikipedia.org/wiki/Plan_de_num%C3%A9rotation_en_France (bonne lecture).

Agate Berriot a écrit :

Ça me parait top, une question : je vois qu'on concatène le phone_prefix et le numéro de téléphone pour construire l'identifiant pour la requête. Ça risque pas de bugger sur des inputs type 0612345678 (avec la concaténation, on aura un +330612345678), à matcher avec potentiellement un +33612345678, sans le zéro ? Il me semble qu'un·e utilisateur aura tendance à taper son numéro avec le 0 comme préfixe mais je peux me tromper.

Je m’imaginais faire d’abord un truc qui marche pour les numéros français, avec dans #69222 une aide à la saisie lorsque le préfixe français est sélectionné (par exemple en isolant le premier chiffre puis en regroupant deux par deux les huit chiffres suivants, afin que l’usager capte bien que le zéro initial saute). Mais j’ai zappé ce que Thomas met ici et donc il me faut revoir ma copie :)

Sans cette hypothèse, j’avoue que je ne sais pas trop de quelle façon on peut restreindre davantage ici, notamment parce que https://en.wikipedia.org/wiki/Telephone_numbers_in_Belgium, page à laquelle je ne comprends rien :)

Plus généralement, peut-être que ça a été déjà discuté ailleurs, comment se passe la normalisation des numéros avant stockage en base ?

Non, pas discuté ailleurs, et ici et maintenant peut être l’occasion d’en discuter. J’avais en tête de faire dans #69222 un maximum de sanitization de l’input en front, pour réduire au maximum les écarts entre les données collectées par le formulaire et la version stockée en base. Typiquement juste une suite de chiffres sans le zéro initial, qu’on pourrait vérifier facilement ensuite sans normalisation à proprement parler. J’avais peur qu’à tolérer de trop grands écarts on loupe des choses à la normalisation, genre l’usager qui tape un caractère d’espacement exotique (espace semi-fine insécable " ", tirets typographiques "–" ou encore "—", etc.) qui casserait toute l’affaire. Mais peut-être cette approche est une mauvaise idée, on peut en discuter ici.

À part ces questions, c'est okay pour moi :)

Cool, merci pour ta relecture. Je vais avancer sur les autres tickets liés à #49212 pour pouvoir proposer une démo complète avant qu’on envisage passer tous ces patches.

Thomas Noël a écrit :

Agate Berriot a écrit :

Ça me parait top, une question : je vois qu'on concatène le phone_prefix et le numéro de téléphone pour construire l'identifiant pour la requête. Ça risque pas de bugger sur des inputs type 0612345678 (avec la concaténation, on aura un +330612345678), à matcher avec potentiellement un +33612345678, sans le zéro ? Il me semble qu'un·e utilisateur aura tendance à taper son numéro avec le 0 comme préfixe mais je peux me tromper.

Agate a raison... bienvenue en enfer, Paul ;)

Je vais ajouter qu'il faut ajouter dans les settings les préfixes des DROM, qui font partie du https://fr.wikipedia.org/wiki/Plan_de_num%C3%A9rotation_en_France (bonne lecture).

Pour moi la solution durable, c'est de prendre une bibliothèque type https://pypi.org/project/phonenumbers/#description et tout normaliser via ce biais avant de stocker ou faire des comparaisons. Ça nous permettra de gérer du même coup les espaces, tirets, tous les formats un peu chelous avec les parenthèses, les préfixes avec + ou les doubles 00. Surtout si on commence à accepter des numéros d'autres pays ou de territoires avec des préfixes ou des structures différentes et qu'on bricole un truc maison, ça va être ingérable.

Agate Berriot a écrit :

Pour moi la solution durable, c'est de prendre une bibliothèque type https://pypi.org/project/phonenumbers/#description et tout normaliser via ce biais avant de stocker ou faire des comparaisons. Ça nous permettra de gérer du même coup les espaces, tirets, tous les formats un peu chelous avec les parenthèses, les préfixes avec + ou les doubles 00. Surtout si on commence à accepter des numéros d'autres pays ou de territoires avec des préfixes ou des structures différentes et qu'on bricole un truc maison, ça va être ingérable.

Oui, sûr, surtout ne rien bricoler. Je vais regarder cette bibliothèque, déjà empaquetée dans Debian. Je note aussi que des gens ont fait le taff d’intégration directe de cette bibliothèque nativement dans Django, ça donne https://django-phonenumber-field.readthedocs.io/en/latest/, ça a l’air maintenu et c’est aussi disponible dans les dépôts standards Debian.

Paul Marillonnet a écrit :

[…] Je note aussi que des gens ont fait le taff d’intégration directe de cette bibliothèque nativement dans Django, ça donne https://django-phonenumber-field.readthedocs.io/en/latest/, ça a l’air maintenu et c’est aussi disponible dans les dépôts standards Debian.

Et non, raté, packagé que dans sid.

Et non, raté, packagé que dans sid.

Pas un gros problème ça.

Frédéric Péters a écrit :

Pas un gros problème ça.

Ok, noté, je regarde plus en détails.

Thomas Noël a écrit :

Je vais ajouter qu'il faut ajouter dans les settings les préfixes des DROM, qui font partie du https://fr.wikipedia.org/wiki/Plan_de_num%C3%A9rotation_en_France (bonne lecture).

Ça dit :

Tous les correspondants du territoire national (métropole ou DOM) peuvent s'appeler entre eux en utilisant le plan de numérotation français à dix chiffres, sans composer le code pays pour la voix, les SMS et les MMS. À Saint-Pierre-et-Miquelon, les abonnés peuvent se joindre en composant les six derniers chiffres de leurs numéros. 

Je suis d'avis de ne rien faire de tout ça, d'accepter seulement ^0[67][0-9]{8}$ et l'équivalent pour la Belgique et d'avoir en dur une fonction pour convertir ça vers le numéro à appeler (et idem à l'enregistrement/la modification).

Benjamin Dauvergne a écrit :

Je vais ajouter qu'il faut ajouter dans les settings les préfixes des DROM, qui font partie du https://fr.wikipedia.org/wiki/Plan_de_num%C3%A9rotation_en_France (bonne lecture).

Ça dit :
[...]
je pense que les numéros mobiles sont exposés sur les toutes les indicatifs nationaux du plan de numérotation, donc on peut mettre +33 tout le temps.

Hmm, à lire de la doc ici et là à ce sujet, il est dit que ça marche parce que les opérateurs savent “en général” reconstituer le code pays lorsqu’on tape un numéro à dix chiffres sans préfixe. Donc j’ai l’impression que justement non on ne peut pas mettre +33 tout le temps, l’intelligence est du côté opérateur qui retrouve le code. Quelqu’un a une compréhension différente de l’affaire ?

Est-ce qu’on est sûr que ça va marcher quand on a recours à un service tiers d’envoi de SMS ? Notamment est-ce que ces services acceptent systématiquement d’envoyer à numéros à dix chiffres sans mention du code pays ? Ou bien est-ce à nous de retrouver ce code avant l’appel au service d’envoi (auquel cas il faut aller dans le sens de ce que propose Agate) ?

Bref trop d’interrogations, avant de poursuivre je dois me renseigner là-dessus.

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Je vais ajouter qu'il faut ajouter dans les settings les préfixes des DROM, qui font partie du https://fr.wikipedia.org/wiki/Plan_de_num%C3%A9rotation_en_France (bonne lecture).

Ça dit :
[...]
je pense que les numéros mobiles sont exposés sur les toutes les indicatifs nationaux du plan de numérotation, donc on peut mettre +33 tout le temps.

Hmm, à lire de la doc ici et là à ce sujet, il est dit que ça marche parce que les opérateurs savent “en général” reconstituer le code pays lorsqu’on tape un numéro à dix chiffres sans préfixe. Donc j’ai l’impression que justement non on ne peut pas mettre +33 tout le temps, l’intelligence est du côté opérateur qui retrouve le code. Quelqu’un a une compréhension différente de l’affaire ?

Est-ce qu’on est sûr que ça va marcher quand on a recours à un service tiers d’envoi de SMS ? Notamment est-ce que ces services acceptent systématiquement d’envoyer à numéros à dix chiffres sans mention du code pays ? Ou bien est-ce à nous de retrouver ce code avant l’appel au service d’envoi (auquel cas il faut aller dans le sens de ce que propose Agate) ?

Bref trop d’interrogations, avant de poursuivre je dois me renseigner là-dessus.

Pour moi, si on doit s'interfacer avec des services / APIs tiers type Twilio ou SMS Factor, c'est quasiment sûr qu'il faudra un format unique et standard avec le prefixe (par exemple sms factor demande le prefixe 33 pour la france métropolitaine et si je me base sur https://www.smsfactor.com/tarifs-api-sms, il y a un pricing différent pour la Guyane ou la Réunion, et ça m'étonnerait fortement qu'ils fassent de la magie pour reconnaître quoi envoyer où si on ne fournit pas le bon indicateur pays).

On peut peut-être poussé tout ce qui est widget/field ici, et garder les aspects formulaire d'authent dans un autre ticket, pour avancer.

Benjamin Dauvergne a écrit :

On peut peut-être poussé tout ce qui est widget/field ici, et garder les aspects formulaire d'authent dans un autre ticket, pour avancer.

Ok, je fais un autre ticket.

Benjamin Dauvergne a écrit :

• je ne suis pas pour l'ajout d'un PhoneField dans LoginForm, ça complexifie,

L’idée est de faire dans #69222 le travail en front de simplification, avoir un switch pour que l’un ou l’autre des champs email et téléphone s’affiche à l’usager dans la mire d’authentification, mais pas les deux à là fois.

• le PhoneField devrait sélectionner le pays par défaut

Ok.

• le champ indicatif devrait rappeler le territoire avant l'indicatif "Guyane française (+xxx)", y a peut-être moyen d'extraire ça de libphonenumber d'aillerus

Ok.

Automatic expiration