developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 13 years ago

Closed 13 years ago

#297 closed bug (fixed)

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

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

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@… is considered as valid
  • arnaudj@… 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@… est considérée comme valide.
  • arnaudj@… est considérée comme invalide, alors qu'elle est valide.

Attachments (2)

jforms-patch.diff (812 bytes) - added by arnaudj 13 years ago.
may fix this bug
filter-tests-patch.diff (2.6 KB) - added by arnaudj 13 years ago.
regex correcte + tests unitaires

Download all attachments as: .zip

Change History (12)

Changed 13 years ago by arnaudj

may fix this bug

comment:1 Changed 13 years ago by laurentj

  • Priority changed from normal to low
  • Resolution set to fixed
  • Status changed from new to closed

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

Changed 13 years ago by arnaudj

regex correcte + tests unitaires

comment:2 Changed 13 years ago by arnaudj

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:3 Changed 13 years ago 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@…_x est invalide. Par contre name@… 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é.

comment:4 Changed 13 years ago 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!)

comment:5 Changed 13 years ago 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 ;-)

comment:6 Changed 13 years ago 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.

comment:7 Changed 13 years ago 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.

comment:8 Changed 13 years ago 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

comment:9 Changed 13 years ago 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.

comment:10 Changed 13 years ago by laurentj

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.