Produits Entr'ouvert » Corbo

Voir #14093 pour la discussion sur les formats.

En relisant l'ensemble, je suis un peu perplexe. Pourquoi normaliser la cible sms: alors qu'on considère que les mailto: c'est toujours OK ? Je veux dire, faut faire l'un et l'autre, ou ni l'un ni l'autre, mais pas l'un ou l'autre. Non ?

Les mails sont déjà normés, puisqu'ils sont issus (presque tout le temps) d'authentic. Quant aux numéros de téléphone, on souhaite pouvoir trouver l'abonnement d'un usager qu'il ait tapé son numéro en "06 07 ..." ou "+336 07..", etc.

Serghei Mihai a écrit :

Les mails sont déjà normés, puisqu'ils sont issus (presque tout le temps) d'authentic. Quant aux numéros de téléphone, on souhaite pouvoir trouver l'abonnement d'un usager qu'il ait tapé son numéro en "06 07 ..." ou "+336 07..", etc.

Et donc... on a un webservice qui fait confiance aux mails, mais pas aux SMS, parce qu'il sait que les mails sont déjà bons, alors que les SMS il ne sait pas. Ça va pas.

Il suffit que le logiciel qui envoie la demande d'abonnement soit aussi rusé avec les SMS qu'avec les mails.

Autrement dit, il suffit comme pour les mails que les numéros de SMS soient vérifiés à la source. Au moins sur le format. À terme, comme pour les mails, on fera un aller-retour pour vérifier que la personne nous a donné son numéro de SMS et n'a pas abonné une personne qu'elle a envie de faire ch*er.

Bref, je suis vraiment pas fan d'avoir des traitements différents pour des trucs qu'on pourrait valider tout pareil. Et pour moi c'est pas dans Corbo qu'il faut jouer.

Concernant la recherche, Benjamin a donné la réponse ailleurs, il suffira de tester en ajoutant/retirant 0033, +33, etc (et j'ai mis 33 mais ça dépend du pays, of course ; et si on veut être compatible "monde" c'est encore une autre affaire, faut mieux déjà oublier).

Thomas Noël a écrit :

Concernant la recherche, Benjamin a donné la réponse ailleurs, il suffira de tester en ajoutant/retirant 0033, +33, etc (et j'ai mis 33 mais ça dépend du pays, of course ; et si on veut être compatible "monde" c'est encore une autre affaire, faut mieux déjà oublier).

C'est idiot ce que tu dis ©. On est en France, et on a que des clients français, un type avec un numéro étranger par exemple Belge, il s'inscrira soit avec +32 ou 0032, et quand on le cherchera on le cherchera forcément sous cette forme là (et on a prévu de savoir remplacer 00 par + et inversement), il n'y a que si on repère une recherche pour un numéro local (donc un seul 0 devant) qu'on ajoute +33 ou 0033.

Au pire si on doit installer du corbo en Belgique on rendra ces règles modifiables mais on fera pareil (+32 ou 0032, etc..).

• tu envoies un secret par SMS à la personne, la personne rentre le secret, c'est fini, voir docbow (http://git.entrouvert.org/docbow.git/tree/docbow_project/docbow/forms.py#n440). Ici c'est fait via une méthode clean_xxx() d'un Form, ça pourrait être fait dans un widget pour être réutilisable dans combo (pour la cellule d'inscription anonyme) et authentic (pour le champ de profil, téléphone mobile). C'est chiant sur plusieurs points:
  • ça coûte de l'argent (par rapport aux campagnes de mailing derrière c'est peanuts, m'enfin c'est pas gratuit comme le mail)
  • ça marche un peu quand ça veut
    1. parce qu'on utilise OVH qui n'est pas un spameur de SMS sérieux,
    2. parce qu'on est obligé d'envoyer le SMS en mode "stop", i.e. mode SPAM, puisque justement à ce stade on ne sait pas si la personne est bien celle qui s'inscrit, or dans ce mode les SMS ne passent qu'aux heures ouvrés (vaguement entre 8h/10h et 20h le soir, et pas les week-ends)
• tu génères un secret que tu files à la personne et tu lui demandes de l'envoyer par SMS à un numéro (voir tu lui files rien de secret, juste tu checkes le numéro que tu reçois par SMS, je sais qu'on peut forger les numéro d'envoi via les plate-formes, mais c'est pas évident pour les quidams qu'on vise); sur réception d'un SMS on ajoute le numéro à une liste de numéro récemment validés sur un service partagé par tous nos clients, et le widget "PhoneNumber" appelle ce service pour valider le numéro (voir on a en plus un WS ajax cross-origin pour pouvoir tout de suite dire à la personne, c'est bon coco t'es validé), les numéros validés sont mis en cache pour 5 minutes,
  • ça ne coûte presque rien, pour un numéro partagé chez mobyt c'est du 30 euros par an (mais ça oblige à ajouter un préfixe au jeton dans le SMS) sinon 150e/mois pour un numéro dédié
  • ça passera toujours

Moi la solution deux me plaît bien.

Benjamin Dauvergne a écrit :

C'est idiot ce que tu dis ©. On est en France, et on a que des clients français

IMIO, quand même, au moins.

Sinon je n'ai pas dit que je voulais une vérification du SMS mainteant, mais "à terme". Pour l'instant je dis que c'est le format qu'on pourrait vérifier, mais dès la saisie, parce que c'est idiot© de stocker un format foireux dans des demandes wcs ou dans des profils Authentic ; alors qu'on a codé un redressage dans corbo... Je préfère que corbo, il gère ça comme pour les mails : il fait confiance au demandeur.

Pour faire un check du SMS, on est tout à fait d'accord, faudrait le faire sérieusement, et ça sera pas avec spamOVH, mais plutôt avec des spécialistes genre https://www.twilio.com/sms

Moi la solution deux me plaît bien.

Celle où c'est le client qui paye ? ;-) Petit salopio.

Thomas Noël a écrit :

Benjamin Dauvergne a écrit :

C'est idiot ce que tu dis ©. On est en France, et on a que des clients français

IMIO, quand même, au moins.

Sinon je n'ai pas dit que je voulais une vérification du SMS mainteant, mais "à terme". Pour l'instant je dis que c'est le format qu'on pourrait vérifier, mais dès la saisie, parce que c'est idiot© de stocker un format foireux dans des demandes wcs ou dans des profils Authentic ; alors qu'on a codé un redressage dans corbo... Je préfère que corbo, il gère ça comme pour les mails : il fait confiance au demandeur.

Tu veux vérifier quoi ? qu'on reçoit uniquement du (0033|+33|0)[67][0-9]{10} (un numéro français) ou du (00|+)(\d[0-24-9]|[0-24-9]\d)\d* (autre chose) ?

Benjamin Dauvergne a écrit :

Tu veux vérifier quoi ? qu'on reçoit uniquement du (0033|+33|0)[67][0-9]{10} (un numéro français) ou du (00|+)(\d[0-24-9]|[0-24-9]\d)\d* (autre chose) ?

Mais je m'en fous ! Je dis juste que c'est pas dans corbo que ça doit être fait.

Mais il faut le faire partout, le jour où ce sera liferay qui nous enverra des numéros on sera bien content.

Benjamin Dauvergne a écrit :

Mais il faut le faire partout, le jour où ce sera liferay qui nous enverra des numéros on sera bien content.

Sachant aussi que dans les use-case de corbo il y a aussi en BO le fait pour la commune de pouvoir injecter des listes de mail ou de numéro venant d'un système tiers (j'ai les mobiles dans mon logiciel enfance, comment je fais pour envoyer des annonces ?).

Benjamin Dauvergne a écrit :

Mais il faut le faire partout, le jour où ce sera liferay qui nous enverra des numéros on sera bien content.

Ok, donc pareil pour les mails (c'est vraiment tout ce que je demande, si on considère que les mails c'est toujours bon et pas les téléphones, let's go)

Oui, dans nos web-services on doit contrôler ce qu'on nous envoie mail ou SMS, au niveau corbo on va considérer que les données sont validées au niveau confiance (c'est bien l'email ou le SMS d'un personne intéressée par l'abonnement) mais pas forcément au niveau format.

Benjamin Dauvergne a écrit :

Oui, dans nos web-services on doit contrôler ce qu'on nous envoie mail ou SMS, au niveau corbo on va considérer que les données sont validées au niveau confiance (c'est bien l'email ou le SMS d'un personne intéressée par l'abonnement) mais pas forcément au niveau format.

Ok, tu as trouvé le bon argumentaire. Relisons maintenant le patch de Josué et désolé d'avoir pollué le ticket.

Donc dans le patch de Josué, il faut toujours accepter le numéro, mais juste le reformatter. ie revoir le patch. Mon avis : retirer tout ce qui serait entre parenthèse, puis tout ce qui n'est pas chiffre, sauf l'éventuel + de départ.

Je préférerais quelque chose de plus général que :

            phonenumber = re.sub('\(\d+\)', '', phonenumber)
            phonenumber = re.sub('[-.\s]', '', phonenumber)

qui fait qu'on "risque" de conserver des numéros avec autre chose que des chiffres, qui laisserait passer plusieurs '+' de suite, etc.

Je proposerai :

n = re.sub('\(.*?\)', '', n)       # retire les machins entre parenthèses (mauvaise habitude française du +33(0)123456789)
n = re.sub('[^\d+]', '', n)        # retire tout sauf numéros et +
if n:
    n = n[0] + re.sub('[^\d]', '', n)  # ne garde que le + de départ

Et ajouter un test sur un même numéro écrit de plein de façons bizarres.

Dans models.py l'import de ValidationError est inutile.

Dans la migration:

    uri = 'sms:'
    for subscription in Subscription.objects.filter(identifier__startswith='sms:'):
        ...

il faudrait utiliser la variable uri dans le filtre, non?

Et

from django.core.exceptions import ValidationError

Je pensais l'avoir noté quelque part mais visiblement perdu, une succession de trois regex, sans commentaire notant l'intention, je trouve que c'est compliqué à comprendre.

    phonenumber = re.sub('\(.*?\)', '', phonenumber)  # retire je ne sais quoi
    phonenumber = re.sub('[^\d+]', '', phonenumber)  # retire ce qui n'est pas chiffres au début, peut-être ?
    if phonenumber:  # il reste un truc (mais quoi ?)
        phonenumber = phonenumber[0] + re.sub('[^\d]', '', phonenumber[1:])  # retire à nouveau tout ce qui n'est pas chiffres, sauf le premier caractère ?

1. (0): case of +33 (0) 6 10 20 30 40

→ parenthesis and their contents.

2. every characters but numbers

→ la regex c'est plutôt, a priori : every characters but numbers AND plus signs.

3. every plus sign (+) but the one at the beginning

→ all plus signs after the first character.

_~~

Étant donné 0033+610203040+ qui me laisse penser qu'on s'autorise à tester des trucs qui ne seraient jamais tapés, ou presque, il m'arrive d'avoir le doigt lourd et de taper +33 (0)) 6 10 20 30 40. Parfois aussi je glisse et je tape genre 06.10.20:30.40.

En fait le numéro avec le : en trop il me semble exploser avant (uri, phonenumber = self.identifier.split(':'))

Ack