Ticket #297 (closed bug: fixed)

Opened 1 year ago

Last modified 1 year ago

Erreur de validation d'adresse email par jFilter et la fonction javascript verifyForm

Reported by: arnaudj Assigned to:
Priority: low Milestone: Jelix 1.0beta3.1
Component: jelix:forms Version: trunk
Severity: normal Keywords:
Cc: Php version:
Review: Hosting Provider:
Documentation needed: Blocking:

Description

English

In jForm, there is a bug in email type fields validation by the javascript function verifyForm. When an email contains a sub-domain (ie. when the domain name part of the email contains more than one dot), it is considered as invalid.

Here is an example :

  • arnaudj@provider.com is considered as valid
  • arnaudj@mail.provider.com is considered as invalid... but in fact it's valid !

French

Dans jForm, la validation des champs de type email par la fonction javascript verifyForm n'est pas correcte. En effet, cette fonction considère comme erronées les adresses électroniques qui comportent un sous-domaine, et qui contiennent donc plus d'un point dans le nom de domaine.

Par exemple :

  • arnaudj@provider.com est considérée comme valide.
  • arnaudj@mail.provider.com est considérée comme invalide, alors qu'elle est valide.

Attachments

jforms-patch.diff (0.8 kB) - added by arnaudj on 10/06/07 00:15:05.
may fix this bug
filter-tests-patch.diff (2.6 kB) - added by arnaudj on 10/06/07 17:53:23.
regex correcte + tests unitaires

Change History

10/06/07 00:15:05 changed by arnaudj

  • attachment jforms-patch.diff added.

may fix this bug

10/06/07 09:54:33 changed by laurentj

  • priority changed from normal to low.
  • status changed from new to closed.
  • resolution set to fixed.

Désolé, le patch n'est pas bon. En fait il manque juste + après l'avant-dernière parenthèse. Même bug dans jFilter au passage...

Bug corrigé dans le trunk et la branche 1.0beta3.x

10/06/07 17:53:23 changed by arnaudj

  • attachment filter-tests-patch.diff added.

regex correcte + tests unitaires

10/06/07 18:02:47 changed by arnaudj

  • status changed from closed to reopened.
  • resolution deleted.

La solution appliquée, moins stricte que celle que j'avais proposée dans le précédent patch, laisse passer des adresses email invalides. Pour illustrer mon propos, je fournis des exemples de tests unitaires dans le nouveau patch filter-tests-patch.diff :

  • name@etudiant.univ-lille1 est considérée comme valide actuellement, alors que l'extension est manquante
  • name@provider.x_x est considérée comme valide actuellement, alors que l'extension est fantaisiste.

filter-tests-patch.diff corrige donc cette erreur.

10/07/07 18:49:29 changed by laurentj

Il y a effectivement une erreur : le caractère souligné est interdit dans le nom de domaine (mais pas dans le nom de la boite aux lettres). Donc effectivement, name@provider.x_x est invalide. Par contre name@etudiant.univ-lille1 est tout a fait valide (et même name@univ-lille1). Voir RFC 1034 section 3.5 pour la validité d'un nom de domaine. Donc patch refusé.

10/07/07 19:41:22 changed by arnaudj

Je n'avais pas pensé à ce cas particulier, vu qu'il ne s'applique pas aux emails sur Internet, où l'extension (TLD) est obligatoire. Cas tellement particulier que je me demande s'il est utile de le prendre en compte : je crois que presque tous les sites souhaitent refuser les adresses sans TLD... Quant aux soulignés, c'était clairement une erreur de les tolérer (mea culpa!)

10/07/07 20:32:35 changed by laurentj

Je n'avais pas pensé à ce cas particulier, vu qu'il ne s'applique pas aux emails sur Internet, où l'extension (TLD) est obligatoire

Peux-tu me retrouver la RFC qui le spécifie ? (j'ai pas trop le temps de rechercher maintenant).

Cas tellement particulier que je me demande s'il est utile de le prendre en compte : je crois que presque tous les sites souhaitent refuser les adresses sans TLD

Ça reste à vérifier. Et je pense que c'est plus courant que tu le crois dans le cadre d'intranet ;-)

Quant aux soulignés, c'était clairement une erreur de les tolérer (mea culpa!)

non c'est moi qui devrait dire mea culpa, puisque je les tolére depuis le debut ;-)

10/08/07 09:02:41 changed by arnaudj

  • summary changed from Erreur de validation d'adresse email par la fonction javascript verifyForm to Erreur de validation d'adresse email par jFilter et la fonction javascript verifyForm.

Je pense qu'il s'agit de la RFC 1591.

10/08/07 09:56:19 changed by laurentj

Nulle part il est dit dans cette RFC l'obligation d'avoir un nom de second niveau en plus d'un TLD dans un nom de domaine (ou alors j'ai mal lu..). Cette RFC décrit juste comment sont organisés les TLD sur internet et ce que doivent faire les gestionnaires de TLD. Ça n'empêche nullement une entreprise de gérer sur son intranet qu'un nom de domaine de premier niveau, donc d'avoir des adresses emails du genre toto@mylocaldomain (Personnellement, ça m'est arrivé de le faire sur mon réseau local perso).

Cependant, il est vrai que dans la majorité des cas, on a un TLD + un nom de second niveau.

10/09/07 11:04:27 changed by Uriel C

Au risque de sembler pointilleux : aucun des patch ne prend en compte la RFC 3490 (IDNA, Noms de Domaines Internationalisés) qui autorise les accents et autres caractères internationaux dans un nom de domaine (qui est ensuite converti en Punycode). Il faudrait soit encoder en Punycode avant le filtre, soit adapter les filtres.

http://tools.ietf.org/html/rfc3490

10/11/07 11:20:44 changed by laurentj

@uriel : faut voir si la fonction filter php tiens compte de cette rfc. Le problème ici c'est que ça ne va plus être une expression regulière, mais carrément du parsing de chaine à faire. Ou alors ça sera une regexp monstreuse. Faut voir.

10/16/07 01:03:57 changed by laurentj

  • status changed from reopened to closed.
  • resolution set to fixed.

J'ai corrigé les bugs : j'ai repris la regexp de la fonction PHP filter pour les mails.

Corrigé dans le trunk et la branche beta3

Download in other formats: Comma-delimited Text Tab-delimited Text RSS Feed