Je suis débutant complet en html et php...(amateur)
C'est un exercice que je me suis inventé après quelques autres plus
simples.
je veux vendre 4 articles à des prix définis à l'avance sur le net. Je
demande le nom prénom email et la quantité d'articles. je valide et ça
me récapitule ma commande avec le total.
je selectionne mon mode de paiement et ensuite je confirme la commande
ce qui a pour but d'envoyer un email au webmestre du site avec la
commande complète.
Je pense que mon code HTML est trop lourd (du à frontpage) et
optimisable... mais bon ça, à la limite, je m'en fous un peu...
c'est surtout le php que je voudrais optimiser. Je vois plusieurs
défauts :
- c'est redondant dans les passages de variables, il y a surement un
moyen de faire mieux pour que les variables soient connues sur les 3
pages?
- c'est pas sécurisé surement, je crois qu'on peut bidouiller dans les
champs, et il faut mettre un truc (mais quoi? ) pour éviter que? que
pourrait il arriver d'ailleurs?
- le code est surement extremement maladroit, est il bien présenté?
- j'aurai voulu rajouter un bouton sur la 2eme page: "modifier la
commande" , si ce n'est pas correct revenir à l'ancienne page
saisie.php avec les champs préremplis pour modif , comment faire?
- faut il prendre l'habitude de séparer le code HTML du code PHP sur 2
fichiers différents, j'ai vu ça sur des cours de fac (formulaires,
traitement)
- j'ai essayé de pomper une fonction verifier en javascript mais ça
marche pas, je n'ai jamais fait de javascript. comment vérifier que le
champs a bien été saisi et bloquer l'envoi dans le cas contraire?
comment détecter que l'email est bien de la forme xxxx@xxxx.xx ?
Est ce que vous pourriez vous pencher sur ce code pour émettre le
maximum de critiques afin que je ne prenne pas trop de mauvaises
habitudes?
MERCI BEAUCOUP !!!!
PS: le programme tourne ici :
http://membres.lycos.fr/psylyon/saisie.php (j'ai désactivé l'envoi de
mail)
<h2 align="center">Récapitulatif de votre commande</h2>
<h5>
<? $Q1=$_POST["quantite1"] ; $_SESSION['Q1']=$Q1; // on récupère
les quantités définies à la page de saisie
$Q2=$_POST["quantite2"] ; $_SESSION['Q2']=$Q2;
$Q3=$_POST["quantite3"] ; $_SESSION['Q3']=$Q3;
$Q4=$_POST["quantite4"] ; $_SESSION['Q4']=$Q4;
$nom=$_POST['nom'] ; $_SESSION['nom']=$nom; // on récupère
les infos persos définies à la page de saisie
$prenom= $_POST['prenom'] ;$_SESSION['prenom']=$prenom;
$email= $_POST['email'] ; $_SESSION['email']=$email;
$PU1= $_SESSION['PU1']; // on récupère les prix unitaires
définis à la page de saisie
$PU2= $_SESSION['PU2'];
$PU3= $_SESSION['PU3'];
$PU4= $_SESSION['PU4'];
$article1=$_SESSION['article1']; // on récupère les noms des
articles
$article2=$_SESSION['article2'];
$article3=$_SESSION['article3'];
$article4=$_SESSION['article4'];
$Prix1= $Q1 *$PU1 ; $_SESSION['prix1']=$Prix1 ; // on
calcule les prix pour chaque quantité
$Prix2= $Q2 *$PU2 ; $_SESSION['prix2']=$Prix2 ;
$Prix3= $Q3 *$PU3 ; $_SESSION['prix3']=$Prix3 ;
$Prix4= $Q4 *$PU4 ; $_SESSION['prix4']=$Prix4 ;
<!--mstheme--><font face="Verdana, Arial,
Helvetica"><!--mstheme--></font>
<br><br><br>
<h2> Merci. Votre commande a bien été envoyée! </h2>
<?
$Q1=$_SESSION['Q1'] ; // on récupère les quantités définies à
la page de saisie
$Q2=$_SESSION['Q2'] ;
$Q3=$_SESSION['Q3'] ;
$Q4=$_SESSION['Q4'] ;
$nom=$_SESSION['nom'] ; // on récupère les infos persos
définies à la page de saisie
$prenom=$_SESSION['prenom'] ;
$email= $_SESSION['email'];
$PU1= $_SESSION['PU1']; // on récupère les prix unitaires
définis à la page de saisie
$PU2= $_SESSION['PU2'];
$PU3= $_SESSION['PU3'];
$PU4= $_SESSION['PU4'];
$Prix1= $_SESSION['prix1'] ; // on calcule les prix
pour chaque quantité
$Prix2= $_SESSION['prix2'] ;
$Prix3= $_SESSION['prix3'] ;
$Prix4= $_SESSION['prix4'] ;
$total=$_SESSION['total'];
$article1=$_SESSION['article1']; // on récupère les noms des
articles
$article2=$_SESSION['article2'];
$article3=$_SESSION['article3'];
$article4=$_SESSION['article4'];
$paiement=$_SESSION['paiement']; // mode de paiement
// création des entetes, destinaraire,sujet du message à
envoyer au webmestre
$mailheaders = "From: mon site web <> \n";
$mailheaders .= "Reply-To: $email\n\n";
$destinataire = "monemail@wanadoo.fr";
$sujet = "Une nouvelle commande via mon site web !";
mail($destinataire, $sujet, $msg, $mailheaders);
?>
-----------------------------------------------------------------------------------------------------------------------
--
me répondre via l'adresse email protégée:
http://cerbermail.com/?4s2gdXzrwp
En tant qu'utilisateur de la fonction mail, je suis pas censé connaitre la RFC.
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui te permet de définir les entêtes et le contenu comme tu le veux. Il vaut mieux que tu utilises l'une des versions bridées que l'on trouve en se baladant sur les sites de scripts, ou bien celle que proposait free.fr.
Si les chaines de plus de 78 caracteres doivent être coupées par un "n ", c'est à la fonction mail de le faire, pas à moi.
Cela confirme ce que je disais. Tu cherches une fonction « pour les nuls » (je dis ça sans aucune intention péjorative, exactement comme la collection de bouquins du même nom, ou comme le site du zéro).
Je viens de relire <http://fr.php.net/manual/fr/function.mail.php> et en effet on peut lui reprocher de ne pas mettre suffisamment en garde contre la puissance de cette fonction -- et donc contre les risques que l'on encourt à l'utiliser sans précautions.
La doc dit que le second parametre est le titre, et que si on ne réussit pas à envoyer l'email ca retourne false. Je m'attends à ce que si je passe un titre avec un n dedans, il sera envoyé de façon à ce que ca apparaisse avec un retour chariot chez le client. Si c'est pas possible (et c'est le cas), je m'attends à ce que mail retourne false, pas qu'il envoit un email avec un titre différent à d'autre destinataires.
La doc ne dit rien non plus des entêtes MIME-Version, Content-Type et Content-Transfer-Encoding. Pourtant, ils sont indispensables dès que l'on envoie autre chose qu'un texte en pur ASCII (donc sans aucun caractère accentué par exemple). Mais elle dit quand même :
Note : Les RFCs suivantes peuvent être utiles : RFC 1896, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049 et RFC 2822.
Cordialement, -- Olivier Miakinen
En tant qu'utilisateur de la fonction mail, je suis pas censé connaitre la
RFC.
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui
te permet de définir les entêtes et le contenu comme tu le veux. Il vaut
mieux que tu utilises l'une des versions bridées que l'on trouve en se
baladant sur les sites de scripts, ou bien celle que proposait free.fr.
Si les chaines de plus de 78 caracteres doivent être coupées par un "n
", c'est à la fonction mail de le faire, pas à moi.
Cela confirme ce que je disais. Tu cherches une fonction « pour les
nuls » (je dis ça sans aucune intention péjorative, exactement comme
la collection de bouquins du même nom, ou comme le site du zéro).
Je viens de relire <http://fr.php.net/manual/fr/function.mail.php> et
en effet on peut lui reprocher de ne pas mettre suffisamment en garde
contre la puissance de cette fonction -- et donc contre les risques
que l'on encourt à l'utiliser sans précautions.
La doc dit que le second parametre est le titre, et que si on ne réussit pas
à envoyer l'email ca retourne false. Je m'attends à ce que si je passe un
titre avec un n dedans, il sera envoyé de façon à ce que ca apparaisse avec
un retour chariot chez le client. Si c'est pas possible (et c'est le cas),
je m'attends à ce que mail retourne false, pas qu'il envoit un email avec un
titre différent à d'autre destinataires.
La doc ne dit rien non plus des entêtes MIME-Version, Content-Type et
Content-Transfer-Encoding. Pourtant, ils sont indispensables dès que
l'on envoie autre chose qu'un texte en pur ASCII (donc sans aucun
caractère accentué par exemple). Mais elle dit quand même :
Note : Les RFCs suivantes peuvent être utiles : RFC 1896, RFC 2045,
RFC 2046, RFC 2047, RFC 2048, RFC 2049 et RFC 2822.
En tant qu'utilisateur de la fonction mail, je suis pas censé connaitre la RFC.
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui te permet de définir les entêtes et le contenu comme tu le veux. Il vaut mieux que tu utilises l'une des versions bridées que l'on trouve en se baladant sur les sites de scripts, ou bien celle que proposait free.fr.
Si les chaines de plus de 78 caracteres doivent être coupées par un "n ", c'est à la fonction mail de le faire, pas à moi.
Cela confirme ce que je disais. Tu cherches une fonction « pour les nuls » (je dis ça sans aucune intention péjorative, exactement comme la collection de bouquins du même nom, ou comme le site du zéro).
Je viens de relire <http://fr.php.net/manual/fr/function.mail.php> et en effet on peut lui reprocher de ne pas mettre suffisamment en garde contre la puissance de cette fonction -- et donc contre les risques que l'on encourt à l'utiliser sans précautions.
La doc dit que le second parametre est le titre, et que si on ne réussit pas à envoyer l'email ca retourne false. Je m'attends à ce que si je passe un titre avec un n dedans, il sera envoyé de façon à ce que ca apparaisse avec un retour chariot chez le client. Si c'est pas possible (et c'est le cas), je m'attends à ce que mail retourne false, pas qu'il envoit un email avec un titre différent à d'autre destinataires.
La doc ne dit rien non plus des entêtes MIME-Version, Content-Type et Content-Transfer-Encoding. Pourtant, ils sont indispensables dès que l'on envoie autre chose qu'un texte en pur ASCII (donc sans aucun caractère accentué par exemple). Mais elle dit quand même :
Note : Les RFCs suivantes peuvent être utiles : RFC 1896, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049 et RFC 2822.
Cordialement, -- Olivier Miakinen
Florian Sinatra
*Laurent* @ 30/06/2006 17:51 :
Aïe aïe aïe... je n'ai pas encore lu ton code, mais je regarderai tout particulièrement cette partie. Je dirais à priori que tu as plus de 99 % de chances d'avoir fait un relais à spam.
oui je m'en doutais un peu , c'est pourquoi j'ai désactivé... je suppose qu'un simple test du type : "si il y a autre chose qu'une simple adresse mail alors rejeter l'envoi", ne suffit pas.
Lis les échanges entre Olivier et Vincent de ce matin.
Peut on via un formulaire taper du code php ou autre qui sera interpreté par le serveur? si oui comment empecher ça? (ne pas détailler la réponse ... juste quelques mots ou liens clés me suffiront)
Non. Et il n'y a pas besoin de ca pour mettre la pagaille. Voir plus bas.
Frontpage n'est peut-être pas le meilleur outil pour faire des pages html. Ce n'est pas le pire non plus parce qu'il y a Windows Word qui le bat assurément...
oui j'utilise habituellement notepad ++ mais là j'avais la flemme. je regrette un peu, mais promis, je vais faire un effort? sinon NVU ? dreamweaver? que me conseilles tu?
Rester à Notepad++. On n'est jamais mieux servi que par soi-même. A la limite NVU, mais dans ce cas oublier de modifier le code soi-même.
Il peut arriver plein de choses si tu ne vérifies pas attentivement ce que tu fais des paramètres qui viennent de l'extérieur, par exemple une corruption de ta base de données si tu en utilises, ou l'effacement de tous les fichiers de ton serveur, ou encore l'utilisation de ton script pour aller spammer la terre entière en toute impunité.
comment peut on accèder aux fichiers serveurs sur mon code actuel? ça me parait étrange? en mettant du code dans les entrées de formulaires? ça m'intereserait de savoir.
Pour les bases de données, par exemple par injection SQL, c'est-à-dire que si l'appli ne vérifie pas les chaînes recues et créé une requête SQL avec, la requête peut contenir des commandes dangereuses.
A lire : <http://saphirtech.com/cours_php.html> et <http://saphirtech.com/securite.html>
Pour pouvoir profiter des services des validateurs automatiques, il serait utile de choisir un DOCTYPE. D'ailleurs cela améliore la compatibilité entre Internet Explorer et le reste du monde.
Et puis c'est comme ca qu'on fait quand on fait bien.
bon je vais voir , je suppose que tu veux parler de tout ce qui est CSS et cie... aie.. bon, encore du boulot !
vous connaissez des liens vers des cours en ligne (à part le site du zéro) ?
Remplacer « langage="javascript" » par « type="text/javascript" » (je te dis ça de mémoire, mais c'est hors sujet ici -- à vérifier sur fciwa ou sur fclj)
je laisse tomber ça pour l'instant.
Au point où en est l'HTML, tu as raison.
Il vaudrait mieux déclarer le charset dans les entêtes HTTP. Tiens, je vais vérifier si c'est fait...
j'y comprends rien à ça.. d'habitude, je mets rien c'est mieux? la c frontpage qui a mis !
Aïe aïe aïe... je n'ai pas encore lu ton code, mais je regarderai tout
particulièrement cette partie. Je dirais à priori que tu as plus de 99 %
de chances d'avoir fait un relais à spam.
oui je m'en doutais un peu , c'est pourquoi j'ai désactivé... je
suppose qu'un simple test du type : "si il y a autre chose qu'une
simple adresse mail alors rejeter l'envoi", ne suffit pas.
Lis les échanges entre Olivier et Vincent de ce matin.
Peut on via un formulaire taper du code php ou autre qui sera
interpreté par le serveur? si oui comment empecher ça? (ne pas
détailler la réponse ... juste quelques mots ou liens clés me
suffiront)
Non. Et il n'y a pas besoin de ca pour mettre la pagaille. Voir plus bas.
Frontpage n'est peut-être pas le meilleur outil pour faire des pages
html. Ce n'est pas le pire non plus parce qu'il y a Windows Word qui
le bat assurément...
oui j'utilise habituellement notepad ++ mais là j'avais la flemme. je
regrette un peu, mais promis, je vais faire un effort? sinon NVU ?
dreamweaver?
que me conseilles tu?
Rester à Notepad++. On n'est jamais mieux servi que par soi-même. A la
limite NVU, mais dans ce cas oublier de modifier le code soi-même.
Il peut arriver plein de choses si tu ne vérifies pas attentivement ce
que tu fais des paramètres qui viennent de l'extérieur, par exemple une
corruption de ta base de données si tu en utilises, ou l'effacement de
tous les fichiers de ton serveur, ou encore l'utilisation de ton script
pour aller spammer la terre entière en toute impunité.
comment peut on accèder aux fichiers serveurs sur mon code actuel? ça
me parait étrange? en mettant du code dans les entrées de formulaires?
ça m'intereserait de savoir.
Pour les bases de données, par exemple par injection SQL, c'est-à-dire
que si l'appli ne vérifie pas les chaînes recues et créé une requête SQL
avec, la requête peut contenir des commandes dangereuses.
A lire : <http://saphirtech.com/cours_php.html> et
<http://saphirtech.com/securite.html>
Pour pouvoir profiter des services des validateurs automatiques, il
serait utile de choisir un DOCTYPE. D'ailleurs cela améliore la
compatibilité entre Internet Explorer et le reste du monde.
Et puis c'est comme ca qu'on fait quand on fait bien.
bon je vais voir , je suppose que tu veux parler de tout ce qui est
CSS et cie... aie.. bon, encore du boulot !
vous connaissez des liens vers des cours en ligne (à part le site du
zéro) ?
Remplacer « langage="javascript" » par « type="text/javascript" »
(je te dis ça de mémoire, mais c'est hors sujet ici -- à vérifier sur
fciwa ou sur fclj)
je laisse tomber ça pour l'instant.
Au point où en est l'HTML, tu as raison.
Il vaudrait mieux déclarer le charset dans les entêtes HTTP. Tiens, je
vais vérifier si c'est fait...
j'y comprends rien à ça.. d'habitude, je mets rien c'est mieux? la c
frontpage qui a mis !
Aïe aïe aïe... je n'ai pas encore lu ton code, mais je regarderai tout particulièrement cette partie. Je dirais à priori que tu as plus de 99 % de chances d'avoir fait un relais à spam.
oui je m'en doutais un peu , c'est pourquoi j'ai désactivé... je suppose qu'un simple test du type : "si il y a autre chose qu'une simple adresse mail alors rejeter l'envoi", ne suffit pas.
Lis les échanges entre Olivier et Vincent de ce matin.
Peut on via un formulaire taper du code php ou autre qui sera interpreté par le serveur? si oui comment empecher ça? (ne pas détailler la réponse ... juste quelques mots ou liens clés me suffiront)
Non. Et il n'y a pas besoin de ca pour mettre la pagaille. Voir plus bas.
Frontpage n'est peut-être pas le meilleur outil pour faire des pages html. Ce n'est pas le pire non plus parce qu'il y a Windows Word qui le bat assurément...
oui j'utilise habituellement notepad ++ mais là j'avais la flemme. je regrette un peu, mais promis, je vais faire un effort? sinon NVU ? dreamweaver? que me conseilles tu?
Rester à Notepad++. On n'est jamais mieux servi que par soi-même. A la limite NVU, mais dans ce cas oublier de modifier le code soi-même.
Il peut arriver plein de choses si tu ne vérifies pas attentivement ce que tu fais des paramètres qui viennent de l'extérieur, par exemple une corruption de ta base de données si tu en utilises, ou l'effacement de tous les fichiers de ton serveur, ou encore l'utilisation de ton script pour aller spammer la terre entière en toute impunité.
comment peut on accèder aux fichiers serveurs sur mon code actuel? ça me parait étrange? en mettant du code dans les entrées de formulaires? ça m'intereserait de savoir.
Pour les bases de données, par exemple par injection SQL, c'est-à-dire que si l'appli ne vérifie pas les chaînes recues et créé une requête SQL avec, la requête peut contenir des commandes dangereuses.
A lire : <http://saphirtech.com/cours_php.html> et <http://saphirtech.com/securite.html>
Pour pouvoir profiter des services des validateurs automatiques, il serait utile de choisir un DOCTYPE. D'ailleurs cela améliore la compatibilité entre Internet Explorer et le reste du monde.
Et puis c'est comme ca qu'on fait quand on fait bien.
bon je vais voir , je suppose que tu veux parler de tout ce qui est CSS et cie... aie.. bon, encore du boulot !
vous connaissez des liens vers des cours en ligne (à part le site du zéro) ?
Remplacer « langage="javascript" » par « type="text/javascript" » (je te dis ça de mémoire, mais c'est hors sujet ici -- à vérifier sur fciwa ou sur fclj)
je laisse tomber ça pour l'instant.
Au point où en est l'HTML, tu as raison.
Il vaudrait mieux déclarer le charset dans les entêtes HTTP. Tiens, je vais vérifier si c'est fait...
j'y comprends rien à ça.. d'habitude, je mets rien c'est mieux? la c frontpage qui a mis !
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui te permet de définir les entêtes et le contenu comme tu le veux.
OK, on s'est pas compris. J'ai indiqué mon erreur dans un message plus haut : je parle du parametre subject, pas de " additional_headers". Le parametre subject n'est pas censé te permettre de définir les entêtes et le contenu comme tu veux. La doc indique qu'il sert à indiquer le sujet, rien d'autre.
Si les chaines de plus de 78 caracteres doivent être coupées par un "n ", c'est à la fonction mail de le faire, pas à moi.
Cela confirme ce que je disais. Tu cherches une fonction « pour les nuls » (je dis ça sans aucune intention péjorative, exactement comme la collection de bouquins du même nom, ou comme le site du zéro).
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour gérer une connection TCP, tu fournis à la socket les données que tu veux envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper les données en paquets, ajouter un header, encapsuler ca dans de l'IP et tout. Tu fournis les données à envoyer et c'est la fonction appelée qui encode ca dans le format qu'elle veut.
La présence même du champs "additional_headers" montre bien que le champs "subject" n'est pas là pour y mettre des headers supplémentaires.
Je viens de relire <http://fr.php.net/manual/fr/function.mail.php> et en effet on peut lui reprocher de ne pas mettre suffisamment en garde contre la puissance de cette fonction -- et donc contre les risques que l'on encourt à l'utiliser sans précautions.
Le fait que tu puisse passer des headers dans le champs subject plutot que le champs additional_header est un bug, ca ne rend pas la fonction plus puissante. Quelqu'un qui utilise ca consciemment cherche les problemes. Si tu veux rajouter des headers supplémentaires, utilises additional_headers. Si j'appelles mail("", "blanBCC:xxx", "content"), je m'attends à ce que ca envoit un mail avec un sujet sur plusieurs lignes (parceque j'ai mis un sujet sur plusieurs lignes dans le champ subject), soit que ca retourne false parceque le protocole d'envoie de mail ne permet pas de représenter des sujets sur plusieurs lignes (la RFC indique qu'on peut *encoder* un sujet sur plusieurs lignes, mais que chez le client, ca ne sera pas représenté comme un sujet sur plusieurs lignes).
Si j'écris ca: function TryToLog($login, $pass) { $sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'"; return SQLReturnsResults($sql); }
je dirais que cette fonction est buggée: elle doit appeler mysql_real_escape_string pour encoder les parametres au format SQL. J'attends la même chose de mail: qu'on puisse lui passer les parametres qu'on veut pour subject et content, et qu'elle se débrouille pour encoder ca selon la RFC (ou retourne false si c'est pas possible)
-- Vincent
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui
te permet de définir les entêtes et le contenu comme tu le veux.
OK, on s'est pas compris. J'ai indiqué mon erreur dans un message plus haut
: je parle du parametre subject, pas de " additional_headers". Le parametre
subject n'est pas censé te permettre de définir les entêtes et le contenu
comme tu veux. La doc indique qu'il sert à indiquer le sujet, rien d'autre.
Si les chaines de plus de 78 caracteres doivent être coupées par un "n
", c'est à la fonction mail de le faire, pas à moi.
Cela confirme ce que je disais. Tu cherches une fonction « pour les
nuls » (je dis ça sans aucune intention péjorative, exactement comme
la collection de bouquins du même nom, ou comme le site du zéro).
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la
fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour
gérer une connection TCP, tu fournis à la socket les données que tu veux
envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper
les données en paquets, ajouter un header, encapsuler ca dans de l'IP et
tout. Tu fournis les données à envoyer et c'est la fonction appelée qui
encode ca dans le format qu'elle veut.
La présence même du champs "additional_headers" montre bien que le champs
"subject" n'est pas là pour y mettre des headers supplémentaires.
Je viens de relire <http://fr.php.net/manual/fr/function.mail.php> et
en effet on peut lui reprocher de ne pas mettre suffisamment en garde
contre la puissance de cette fonction -- et donc contre les risques
que l'on encourt à l'utiliser sans précautions.
Le fait que tu puisse passer des headers dans le champs subject plutot que
le champs additional_header est un bug, ca ne rend pas la fonction plus
puissante. Quelqu'un qui utilise ca consciemment cherche les problemes. Si
tu veux rajouter des headers supplémentaires, utilises additional_headers.
Si j'appelles mail("foo@bar.com", "blanBCC:xxx", "content"), je m'attends à
ce que ca envoit un mail avec un sujet sur plusieurs lignes (parceque j'ai
mis un sujet sur plusieurs lignes dans le champ subject), soit que ca
retourne false parceque le protocole d'envoie de mail ne permet pas de
représenter des sujets sur plusieurs lignes (la RFC indique qu'on peut
*encoder* un sujet sur plusieurs lignes, mais que chez le client, ca ne sera
pas représenté comme un sujet sur plusieurs lignes).
Si j'écris ca:
function TryToLog($login, $pass)
{
$sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'";
return SQLReturnsResults($sql);
}
je dirais que cette fonction est buggée: elle doit appeler
mysql_real_escape_string pour encoder les parametres au format SQL.
J'attends la même chose de mail: qu'on puisse lui passer les parametres
qu'on veut pour subject et content, et qu'elle se débrouille pour encoder ca
selon la RFC (ou retourne false si c'est pas possible)
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui te permet de définir les entêtes et le contenu comme tu le veux.
OK, on s'est pas compris. J'ai indiqué mon erreur dans un message plus haut : je parle du parametre subject, pas de " additional_headers". Le parametre subject n'est pas censé te permettre de définir les entêtes et le contenu comme tu veux. La doc indique qu'il sert à indiquer le sujet, rien d'autre.
Si les chaines de plus de 78 caracteres doivent être coupées par un "n ", c'est à la fonction mail de le faire, pas à moi.
Cela confirme ce que je disais. Tu cherches une fonction « pour les nuls » (je dis ça sans aucune intention péjorative, exactement comme la collection de bouquins du même nom, ou comme le site du zéro).
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour gérer une connection TCP, tu fournis à la socket les données que tu veux envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper les données en paquets, ajouter un header, encapsuler ca dans de l'IP et tout. Tu fournis les données à envoyer et c'est la fonction appelée qui encode ca dans le format qu'elle veut.
La présence même du champs "additional_headers" montre bien que le champs "subject" n'est pas là pour y mettre des headers supplémentaires.
Je viens de relire <http://fr.php.net/manual/fr/function.mail.php> et en effet on peut lui reprocher de ne pas mettre suffisamment en garde contre la puissance de cette fonction -- et donc contre les risques que l'on encourt à l'utiliser sans précautions.
Le fait que tu puisse passer des headers dans le champs subject plutot que le champs additional_header est un bug, ca ne rend pas la fonction plus puissante. Quelqu'un qui utilise ca consciemment cherche les problemes. Si tu veux rajouter des headers supplémentaires, utilises additional_headers. Si j'appelles mail("", "blanBCC:xxx", "content"), je m'attends à ce que ca envoit un mail avec un sujet sur plusieurs lignes (parceque j'ai mis un sujet sur plusieurs lignes dans le champ subject), soit que ca retourne false parceque le protocole d'envoie de mail ne permet pas de représenter des sujets sur plusieurs lignes (la RFC indique qu'on peut *encoder* un sujet sur plusieurs lignes, mais que chez le client, ca ne sera pas représenté comme un sujet sur plusieurs lignes).
Si j'écris ca: function TryToLog($login, $pass) { $sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'"; return SQLReturnsResults($sql); }
je dirais que cette fonction est buggée: elle doit appeler mysql_real_escape_string pour encoder les parametres au format SQL. J'attends la même chose de mail: qu'on puisse lui passer les parametres qu'on veut pour subject et content, et qu'elle se débrouille pour encoder ca selon la RFC (ou retourne false si c'est pas possible)
-- Vincent
Calimero
Vincent Lascaux wrote:
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour gérer une connection TCP, tu fournis à la socket les données que tu veux envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper les données en paquets, ajouter un header, encapsuler ca dans de l'IP et tout. Tu fournis les données à envoyer et c'est la fonction appelée qui encode ca dans le format qu'elle veut.
Oui mais par exemple, tu vas quand même te taper la gestion de buffers et l'analyse des données pour extraire tes messages, etc... C'est comme si tu demandais à TCP de faire du SCTP.
Si j'écris ca: function TryToLog($login, $pass) { $sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'"; return SQLReturnsResults($sql); }
je dirais que cette fonction est buggée: elle doit appeler mysql_real_escape_string pour encoder les parametres au format SQL. J'attends la même chose de mail: qu'on puisse lui passer les parametres qu'on veut pour subject et content, et qu'elle se débrouille pour encoder ca selon la RFC (ou retourne false si c'est pas possible)
Ben c'est la même chose ici: la fonction fournie par langage est permissive pour permettre aux gens de faire plein de choses, à eux d'implémenter une surcouche pour contrôler. Si tu as de l'injection SQL, c'est pas à cause mysql_query qui n'escape pas les caractères interdits, mais à cause de *ton* code qui ne le fait pas et qui fournit des données erronées à mysql_query.
PHP fait le choix d'être permissif, et il existe de nombreux codes/projets pour faciliter certaines taches. ADODB/PHPMailer par exemple si tu veux pas t'embêter, puis les fonctions "natives" si tu veux un truc plus rapide et/ou plus ouvert...
-- @+ Calimero
Vincent Lascaux wrote:
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la
fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour
gérer une connection TCP, tu fournis à la socket les données que tu veux
envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper
les données en paquets, ajouter un header, encapsuler ca dans de l'IP et
tout. Tu fournis les données à envoyer et c'est la fonction appelée qui
encode ca dans le format qu'elle veut.
Oui mais par exemple, tu vas quand même te taper la gestion de buffers
et l'analyse des données pour extraire tes messages, etc...
C'est comme si tu demandais à TCP de faire du SCTP.
Si j'écris ca:
function TryToLog($login, $pass)
{
$sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'";
return SQLReturnsResults($sql);
}
je dirais que cette fonction est buggée: elle doit appeler
mysql_real_escape_string pour encoder les parametres au format SQL.
J'attends la même chose de mail: qu'on puisse lui passer les parametres
qu'on veut pour subject et content, et qu'elle se débrouille pour encoder ca
selon la RFC (ou retourne false si c'est pas possible)
Ben c'est la même chose ici: la fonction fournie par langage est
permissive pour permettre aux gens de faire plein de choses, à eux
d'implémenter une surcouche pour contrôler.
Si tu as de l'injection SQL, c'est pas à cause mysql_query qui
n'escape pas les caractères interdits, mais à cause de *ton* code qui
ne le fait pas et qui fournit des données erronées à mysql_query.
PHP fait le choix d'être permissif, et il existe de nombreux
codes/projets pour faciliter certaines taches. ADODB/PHPMailer par
exemple si tu veux pas t'embêter, puis les fonctions "natives" si tu
veux un truc plus rapide et/ou plus ouvert...
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour gérer une connection TCP, tu fournis à la socket les données que tu veux envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper les données en paquets, ajouter un header, encapsuler ca dans de l'IP et tout. Tu fournis les données à envoyer et c'est la fonction appelée qui encode ca dans le format qu'elle veut.
Oui mais par exemple, tu vas quand même te taper la gestion de buffers et l'analyse des données pour extraire tes messages, etc... C'est comme si tu demandais à TCP de faire du SCTP.
Si j'écris ca: function TryToLog($login, $pass) { $sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'"; return SQLReturnsResults($sql); }
je dirais que cette fonction est buggée: elle doit appeler mysql_real_escape_string pour encoder les parametres au format SQL. J'attends la même chose de mail: qu'on puisse lui passer les parametres qu'on veut pour subject et content, et qu'elle se débrouille pour encoder ca selon la RFC (ou retourne false si c'est pas possible)
Ben c'est la même chose ici: la fonction fournie par langage est permissive pour permettre aux gens de faire plein de choses, à eux d'implémenter une surcouche pour contrôler. Si tu as de l'injection SQL, c'est pas à cause mysql_query qui n'escape pas les caractères interdits, mais à cause de *ton* code qui ne le fait pas et qui fournit des données erronées à mysql_query.
PHP fait le choix d'être permissif, et il existe de nombreux codes/projets pour faciliter certaines taches. ADODB/PHPMailer par exemple si tu veux pas t'embêter, puis les fonctions "natives" si tu veux un truc plus rapide et/ou plus ouvert...
-- @+ Calimero
Vincent Lascaux
Oui mais par exemple, tu vas quand même te taper la gestion de buffers et l'analyse des données pour extraire tes messages, etc... C'est comme si tu demandais à TCP de faire du SCTP.
Exactement, si j'utilise une fonction pour faire du TCP, je me soucis uniquement des couches superieures. Dans l'analyse des données, je n'ai pas besoin de connaitre la RFC de TCP... Quand j'utilise la fonction mail qui prend en argument le contenu et le sujet, je ne veux pas me soucier de la façon dont mail va encoder le message...
Si j'écris ca: function TryToLog($login, $pass) { $sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'"; return SQLReturnsResults($sql); }
je dirais que cette fonction est buggée: elle doit appeler mysql_real_escape_string pour encoder les parametres au format SQL.
Ben c'est la même chose ici: la fonction fournie par langage est permissive pour permettre aux gens de faire plein de choses, à eux d'implémenter une surcouche pour contrôler. Si tu as de l'injection SQL, c'est pas à cause mysql_query qui n'escape pas les caractères interdits, mais à cause de *ton* code qui ne le fait pas et qui fournit des données erronées à mysql_query.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien de TryToLog. TryToLog est responsable pour encoder $login et $pass pour pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la même raison, mail est responsable pour encoder $subject, $content de façon à pouvoir l'inserer correctement dans un email.
PHP fait le choix d'être permissif, et il existe de nombreux codes/projets pour faciliter certaines taches. ADODB/PHPMailer par exemple si tu veux pas t'embêter, puis les fonctions "natives" si tu veux un truc plus rapide et/ou plus ouvert...
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce que mail "permet" dans ce bug à part la possibilité d'avoir des injections ? Si tu dis "passer des headers additionels comme sujet", tu as faux. Le parametre sujet n'est pas fait pour ca. Il y a le parametre additional_header pour ca.
-- Vincent
Oui mais par exemple, tu vas quand même te taper la gestion de buffers et
l'analyse des données pour extraire tes messages, etc...
C'est comme si tu demandais à TCP de faire du SCTP.
Exactement, si j'utilise une fonction pour faire du TCP, je me soucis
uniquement des couches superieures. Dans l'analyse des données, je n'ai pas
besoin de connaitre la RFC de TCP...
Quand j'utilise la fonction mail qui prend en argument le contenu et le
sujet, je ne veux pas me soucier de la façon dont mail va encoder le
message...
Si j'écris ca:
function TryToLog($login, $pass)
{
$sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'";
return SQLReturnsResults($sql);
}
je dirais que cette fonction est buggée: elle doit appeler
mysql_real_escape_string pour encoder les parametres au format SQL.
Ben c'est la même chose ici: la fonction fournie par langage est
permissive pour permettre aux gens de faire plein de choses, à eux
d'implémenter une surcouche pour contrôler.
Si tu as de l'injection SQL, c'est pas à cause mysql_query qui n'escape
pas les caractères interdits, mais à cause de *ton* code qui ne le fait
pas et qui fournit des données erronées à mysql_query.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien
de TryToLog. TryToLog est responsable pour encoder $login et $pass pour
pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la
même raison, mail est responsable pour encoder $subject, $content de façon à
pouvoir l'inserer correctement dans un email.
PHP fait le choix d'être permissif, et il existe de nombreux codes/projets
pour faciliter certaines taches. ADODB/PHPMailer par exemple si tu veux
pas t'embêter, puis les fonctions "natives" si tu veux un truc plus rapide
et/ou plus ouvert...
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce
que mail "permet" dans ce bug à part la possibilité d'avoir des injections ?
Si tu dis "passer des headers additionels comme sujet", tu as faux. Le
parametre sujet n'est pas fait pour ca. Il y a le parametre
additional_header pour ca.
Oui mais par exemple, tu vas quand même te taper la gestion de buffers et l'analyse des données pour extraire tes messages, etc... C'est comme si tu demandais à TCP de faire du SCTP.
Exactement, si j'utilise une fonction pour faire du TCP, je me soucis uniquement des couches superieures. Dans l'analyse des données, je n'ai pas besoin de connaitre la RFC de TCP... Quand j'utilise la fonction mail qui prend en argument le contenu et le sujet, je ne veux pas me soucier de la façon dont mail va encoder le message...
Si j'écris ca: function TryToLog($login, $pass) { $sql = "SELECT * FROM Users WHERE login='$login' AND pass='$pass'"; return SQLReturnsResults($sql); }
je dirais que cette fonction est buggée: elle doit appeler mysql_real_escape_string pour encoder les parametres au format SQL.
Ben c'est la même chose ici: la fonction fournie par langage est permissive pour permettre aux gens de faire plein de choses, à eux d'implémenter une surcouche pour contrôler. Si tu as de l'injection SQL, c'est pas à cause mysql_query qui n'escape pas les caractères interdits, mais à cause de *ton* code qui ne le fait pas et qui fournit des données erronées à mysql_query.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien de TryToLog. TryToLog est responsable pour encoder $login et $pass pour pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la même raison, mail est responsable pour encoder $subject, $content de façon à pouvoir l'inserer correctement dans un email.
PHP fait le choix d'être permissif, et il existe de nombreux codes/projets pour faciliter certaines taches. ADODB/PHPMailer par exemple si tu veux pas t'embêter, puis les fonctions "natives" si tu veux un truc plus rapide et/ou plus ouvert...
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce que mail "permet" dans ce bug à part la possibilité d'avoir des injections ? Si tu dis "passer des headers additionels comme sujet", tu as faux. Le parametre sujet n'est pas fait pour ca. Il y a le parametre additional_header pour ca.
-- Vincent
Calimero
Vincent Lascaux wrote:
Exactement, si j'utilise une fonction pour faire du TCP, je me soucis uniquement des couches superieures. Dans l'analyse des données, je n'ai pas besoin de connaitre la RFC de TCP... Quand j'utilise la fonction mail qui prend en argument le contenu et le sujet, je ne veux pas me soucier de la façon dont mail va encoder le message...
Tes sockets te fournissent des fonctionalités brutes: connexion, envoie d'octets dans l'ordre. Il te reste tout le développement de la réception de tes messages (qui peuvent être splittés sur plusieurs recv()). En utilisant des fonctions de bas niveau, tu acceptes de te taper une bonne partie du boulot alors qu'il existe des fonctions/bibliothèques qui te permettent de t'abstraire de certaines tâches. C'est la même chose avec mail(). Tu utilises une fonction de bas niveau, il faut en comprendre les implications. OK, la doc est peut-être un peu light et ne met pas forcément assez en garde par rapport à tout ce qui peut aller de travers.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien de TryToLog. TryToLog est responsable pour encoder $login et $pass pour pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la même raison, mail est responsable pour encoder $subject, $content de façon à pouvoir l'inserer correctement dans un email.
Donc pour une requête SQL tu acceptes de "faire ton boulot" mais pour l'envoi de mail tu veux te décharger complètement sur mail() ?
Pour moi, les deux cas sont mine de rien assez proche: fonction avec des risques intrinsèques connus qu'il faut traiter en amont.
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce que mail "permet" dans ce bug à part la possibilité d'avoir des injections ? Si tu dis "passer des headers additionels comme sujet", tu as faux. Le parametre sujet n'est pas fait pour ca. Il y a le parametre additional_header pour ca.
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se taper un validateur de format de mail, d'alourdir le développement et du coup de casser des applications qui fonctionnent dans un contexte particulier en suivant le comportement spécifié de mail().
Maintenant, on peut effectivement débattre de l'étendue des fonctionnalités de contrôle qu'un langage doit avoir...
-- @+ Calimero
Vincent Lascaux wrote:
Exactement, si j'utilise une fonction pour faire du TCP, je me soucis
uniquement des couches superieures. Dans l'analyse des données, je n'ai pas
besoin de connaitre la RFC de TCP...
Quand j'utilise la fonction mail qui prend en argument le contenu et le
sujet, je ne veux pas me soucier de la façon dont mail va encoder le
message...
Tes sockets te fournissent des fonctionalités brutes: connexion,
envoie d'octets dans l'ordre. Il te reste tout le développement de la
réception de tes messages (qui peuvent être splittés sur plusieurs
recv()). En utilisant des fonctions de bas niveau, tu acceptes de te
taper une bonne partie du boulot alors qu'il existe des
fonctions/bibliothèques qui te permettent de t'abstraire de certaines
tâches. C'est la même chose avec mail(). Tu utilises une fonction de
bas niveau, il faut en comprendre les implications. OK, la doc est
peut-être un peu light et ne met pas forcément assez en garde par
rapport à tout ce qui peut aller de travers.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien
de TryToLog. TryToLog est responsable pour encoder $login et $pass pour
pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la
même raison, mail est responsable pour encoder $subject, $content de façon à
pouvoir l'inserer correctement dans un email.
Donc pour une requête SQL tu acceptes de "faire ton boulot" mais pour
l'envoi de mail tu veux te décharger complètement sur mail() ?
Pour moi, les deux cas sont mine de rien assez proche: fonction avec
des risques intrinsèques connus qu'il faut traiter en amont.
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce
que mail "permet" dans ce bug à part la possibilité d'avoir des injections ?
Si tu dis "passer des headers additionels comme sujet", tu as faux. Le
parametre sujet n'est pas fait pour ca. Il y a le parametre
additional_header pour ca.
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se
taper un validateur de format de mail, d'alourdir le développement et
du coup de casser des applications qui fonctionnent dans un contexte
particulier en suivant le comportement spécifié de mail().
Maintenant, on peut effectivement débattre de l'étendue des
fonctionnalités de contrôle qu'un langage doit avoir...
Exactement, si j'utilise une fonction pour faire du TCP, je me soucis uniquement des couches superieures. Dans l'analyse des données, je n'ai pas besoin de connaitre la RFC de TCP... Quand j'utilise la fonction mail qui prend en argument le contenu et le sujet, je ne veux pas me soucier de la façon dont mail va encoder le message...
Tes sockets te fournissent des fonctionalités brutes: connexion, envoie d'octets dans l'ordre. Il te reste tout le développement de la réception de tes messages (qui peuvent être splittés sur plusieurs recv()). En utilisant des fonctions de bas niveau, tu acceptes de te taper une bonne partie du boulot alors qu'il existe des fonctions/bibliothèques qui te permettent de t'abstraire de certaines tâches. C'est la même chose avec mail(). Tu utilises une fonction de bas niveau, il faut en comprendre les implications. OK, la doc est peut-être un peu light et ne met pas forcément assez en garde par rapport à tout ce qui peut aller de travers.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien de TryToLog. TryToLog est responsable pour encoder $login et $pass pour pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la même raison, mail est responsable pour encoder $subject, $content de façon à pouvoir l'inserer correctement dans un email.
Donc pour une requête SQL tu acceptes de "faire ton boulot" mais pour l'envoi de mail tu veux te décharger complètement sur mail() ?
Pour moi, les deux cas sont mine de rien assez proche: fonction avec des risques intrinsèques connus qu'il faut traiter en amont.
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce que mail "permet" dans ce bug à part la possibilité d'avoir des injections ? Si tu dis "passer des headers additionels comme sujet", tu as faux. Le parametre sujet n'est pas fait pour ca. Il y a le parametre additional_header pour ca.
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se taper un validateur de format de mail, d'alourdir le développement et du coup de casser des applications qui fonctionnent dans un contexte particulier en suivant le comportement spécifié de mail().
Maintenant, on peut effectivement débattre de l'étendue des fonctionnalités de contrôle qu'un langage doit avoir...
-- @+ Calimero
Olivier Miakinen
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui te permet de définir les entêtes et le contenu comme tu le veux.
OK, on s'est pas compris. J'ai indiqué mon erreur dans un message plus haut : je parle du parametre subject, pas de " additional_headers".
Mais encore une fois, le paramètre additional_headers *est* indispensable. À quoi bon faire un semblant de sécurisation du paramètre subject, en emmerdant ceux qui veulent y mettre des FWS tout à fait légitimes, alors que additional_headers va exactement au même endroit et n'est pas (ouvrez les guillemets) « sécurisable » ?
Le parametre subject n'est pas censé te permettre de définir les entêtes et le contenu comme tu veux. La doc indique qu'il sert à indiquer le sujet, rien d'autre.
Oui, et un champ d'entête Subject a le droit de contenir des n, même s'il ne contient qu'un sujet et rien d'autre.
Je ne suis pas sûr que tu aies une idée de l'implémentation de cette fonction mail. Grosso modo, une fonction minimale serait :
function minimal_mail($msg) { system("sendmail<<$msg"); /* je sur-simplifie la lecture de stdin */ }
Une fonction à peine plus évoluée, séparant entêtes et contenu du message, serait :
Pour économiser quelques secondes de programmation, la fonction proposée par PHP est :
function mail($to, $subject, $message, $additional_headers) { $msg = "To: $to" . "n" . "Subject: $subject"; $msg .= "n" . $additional_headers; $msg .= "nn" . $message; minimal_mail($msg); }
Quant à une fonction sécurisée et orientée utilisateur, permettant d'éviter de servir de relais de spam, permettant aussi de contrôler que les adresses sont bien formées et qu'il y a un Content-Type dès qu'un caractère non-ASCII est présent, permettant aussi d'inclure des parties en HTML ou des fichiers joints binaires, cette fonction prendrait un nombre inconsidéré de paramètres et consisterait en quelques milliers de lignes de code. Ce genre de choses existe, mais ce n'est *pas* la fonction mail().
<Aparté en forme de clin d'½il> La preuve que l'exercice est périlleux, est que même le courrielleur- nouvelleur que tu utilises (Outlook Express), dont je présume qu'il se compose de plus qu'une dizaine de lignes de code, échoue lamentablement sur au moins deux des contrôles qu'il pourrait faire :
1) Il t'a laissé mettre un From invalide mais non terminé par .invalid ;
2) Il te laisse utiliser des caractères accentués, mais sans préciser de champs d'entête MIME pour dire comment on doit les interpréter. </Aparté en forme de clin d'½il>
Cela confirme ce que je disais. Tu cherches une fonction « pour les nuls » (je dis ça sans aucune intention péjorative, exactement comme la collection de bouquins du même nom, ou comme le site du zéro).
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour gérer une connection TCP, tu fournis à la socket les données que tu veux envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper les données en paquets, ajouter un header, encapsuler ca dans de l'IP et tout. Tu fournis les données à envoyer et c'est la fonction appelée qui encode ca dans le format qu'elle veut.
Excellent exemple. Quand tu utilises TCP pour implémenter, par exemple, TELNET, tu n'as pas besoin de savoir comment fonctionne TCP, mais c'est à toi de savoir comment marche TELNET.
Ici, c'est la même chose, en remplaçant « TCP » par « SMTP » (RFC 2821), et « TELNET » par « Internet Message Format » (RFC 2822).
La fonction mail() de PHP ne s'occupe *que* du RFC 2821, et c'est à l'utilisateur de connaître le RFC 2822 (plus tous ceux qui se sont greffés par dessus et que SMTP n'a pas à connaître). Si tu veux des fonctions qui te prennent par la main pour cacher les détails du RFC 2822, alors tu vas voir ailleurs : la fonction mail() n'est pas faite pour ça.
Le fait que tu puisse passer des headers dans le champs subject plutot que le champs additional_header est un bug, ca ne rend pas la fonction plus puissante.
Tu ne sembles pas avoir compris ce que je disais, à savoir qu'un n *peut* *légitimement* apparaître dans un champ Subject, et de plus que l'interdire serait appliquer un emplâtre sur une jambe de bois puisque le détournement de cette fonction pour spammer peut se faire ailleurs que dans ce champ.
Quelqu'un qui utilise ca consciemment cherche les problemes. Si tu veux rajouter des headers supplémentaires, utilises additional_headers.
Je n'ai jamais prétendu le contraire. Merci de relire si ce n'est pas évident pour toi (Hint: FWS).
Cordialement, -- Olivier Miakinen
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui
te permet de définir les entêtes et le contenu comme tu le veux.
OK, on s'est pas compris. J'ai indiqué mon erreur dans un message plus haut
: je parle du parametre subject, pas de " additional_headers".
Mais encore une fois, le paramètre additional_headers *est*
indispensable. À quoi bon faire un semblant de sécurisation du
paramètre subject, en emmerdant ceux qui veulent y mettre des
FWS tout à fait légitimes, alors que additional_headers va
exactement au même endroit et n'est pas (ouvrez les guillemets)
« sécurisable » ?
Le parametre
subject n'est pas censé te permettre de définir les entêtes et le contenu
comme tu veux. La doc indique qu'il sert à indiquer le sujet, rien d'autre.
Oui, et un champ d'entête Subject a le droit de contenir des n,
même s'il ne contient qu'un sujet et rien d'autre.
Je ne suis pas sûr que tu aies une idée de l'implémentation de cette
fonction mail. Grosso modo, une fonction minimale serait :
function minimal_mail($msg)
{
system("sendmail<<$msg"); /* je sur-simplifie la lecture de stdin */
}
Une fonction à peine plus évoluée, séparant entêtes et contenu du
message, serait :
Pour économiser quelques secondes de programmation, la fonction proposée
par PHP est :
function mail($to, $subject, $message, $additional_headers)
{
$msg = "To: $to" . "n" . "Subject: $subject";
$msg .= "n" . $additional_headers;
$msg .= "nn" . $message;
minimal_mail($msg);
}
Quant à une fonction sécurisée et orientée utilisateur, permettant
d'éviter de servir de relais de spam, permettant aussi de contrôler que
les adresses sont bien formées et qu'il y a un Content-Type dès qu'un
caractère non-ASCII est présent, permettant aussi d'inclure des parties
en HTML ou des fichiers joints binaires, cette fonction prendrait un
nombre inconsidéré de paramètres et consisterait en quelques milliers
de lignes de code. Ce genre de choses existe, mais ce n'est *pas* la
fonction mail().
<Aparté en forme de clin d'½il>
La preuve que l'exercice est périlleux, est que même le courrielleur-
nouvelleur que tu utilises (Outlook Express), dont je présume qu'il se
compose de plus qu'une dizaine de lignes de code, échoue lamentablement
sur au moins deux des contrôles qu'il pourrait faire :
1) Il t'a laissé mettre un From invalide mais non terminé par .invalid ;
2) Il te laisse utiliser des caractères accentués, mais sans préciser de
champs d'entête MIME pour dire comment on doit les interpréter.
</Aparté en forme de clin d'½il>
Cela confirme ce que je disais. Tu cherches une fonction « pour les
nuls » (je dis ça sans aucune intention péjorative, exactement comme
la collection de bouquins du même nom, ou comme le site du zéro).
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la
fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour
gérer une connection TCP, tu fournis à la socket les données que tu veux
envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper
les données en paquets, ajouter un header, encapsuler ca dans de l'IP et
tout. Tu fournis les données à envoyer et c'est la fonction appelée qui
encode ca dans le format qu'elle veut.
Excellent exemple. Quand tu utilises TCP pour implémenter, par exemple,
TELNET, tu n'as pas besoin de savoir comment fonctionne TCP, mais c'est
à toi de savoir comment marche TELNET.
Ici, c'est la même chose, en remplaçant « TCP » par « SMTP » (RFC 2821),
et « TELNET » par « Internet Message Format » (RFC 2822).
La fonction mail() de PHP ne s'occupe *que* du RFC 2821, et c'est à
l'utilisateur de connaître le RFC 2822 (plus tous ceux qui se sont
greffés par dessus et que SMTP n'a pas à connaître). Si tu veux des
fonctions qui te prennent par la main pour cacher les détails du RFC
2822, alors tu vas voir ailleurs : la fonction mail() n'est pas faite
pour ça.
Le fait que tu puisse passer des headers dans le champs subject plutot que
le champs additional_header est un bug, ca ne rend pas la fonction plus
puissante.
Tu ne sembles pas avoir compris ce que je disais, à savoir qu'un n
*peut* *légitimement* apparaître dans un champ Subject, et de plus que
l'interdire serait appliquer un emplâtre sur une jambe de bois puisque
le détournement de cette fonction pour spammer peut se faire ailleurs
que dans ce champ.
Quelqu'un qui utilise ca consciemment cherche les problemes. Si
tu veux rajouter des headers supplémentaires, utilises additional_headers.
Je n'ai jamais prétendu le contraire. Merci de relire si ce n'est pas
évident pour toi (Hint: FWS).
Alors tu ne dois pas utiliser la fonction toute-puissante mail(), qui te permet de définir les entêtes et le contenu comme tu le veux.
OK, on s'est pas compris. J'ai indiqué mon erreur dans un message plus haut : je parle du parametre subject, pas de " additional_headers".
Mais encore une fois, le paramètre additional_headers *est* indispensable. À quoi bon faire un semblant de sécurisation du paramètre subject, en emmerdant ceux qui veulent y mettre des FWS tout à fait légitimes, alors que additional_headers va exactement au même endroit et n'est pas (ouvrez les guillemets) « sécurisable » ?
Le parametre subject n'est pas censé te permettre de définir les entêtes et le contenu comme tu veux. La doc indique qu'il sert à indiquer le sujet, rien d'autre.
Oui, et un champ d'entête Subject a le droit de contenir des n, même s'il ne contient qu'un sujet et rien d'autre.
Je ne suis pas sûr que tu aies une idée de l'implémentation de cette fonction mail. Grosso modo, une fonction minimale serait :
function minimal_mail($msg) { system("sendmail<<$msg"); /* je sur-simplifie la lecture de stdin */ }
Une fonction à peine plus évoluée, séparant entêtes et contenu du message, serait :
Pour économiser quelques secondes de programmation, la fonction proposée par PHP est :
function mail($to, $subject, $message, $additional_headers) { $msg = "To: $to" . "n" . "Subject: $subject"; $msg .= "n" . $additional_headers; $msg .= "nn" . $message; minimal_mail($msg); }
Quant à une fonction sécurisée et orientée utilisateur, permettant d'éviter de servir de relais de spam, permettant aussi de contrôler que les adresses sont bien formées et qu'il y a un Content-Type dès qu'un caractère non-ASCII est présent, permettant aussi d'inclure des parties en HTML ou des fichiers joints binaires, cette fonction prendrait un nombre inconsidéré de paramètres et consisterait en quelques milliers de lignes de code. Ce genre de choses existe, mais ce n'est *pas* la fonction mail().
<Aparté en forme de clin d'½il> La preuve que l'exercice est périlleux, est que même le courrielleur- nouvelleur que tu utilises (Outlook Express), dont je présume qu'il se compose de plus qu'une dizaine de lignes de code, échoue lamentablement sur au moins deux des contrôles qu'il pourrait faire :
1) Il t'a laissé mettre un From invalide mais non terminé par .invalid ;
2) Il te laisse utiliser des caractères accentués, mais sans préciser de champs d'entête MIME pour dire comment on doit les interpréter. </Aparté en forme de clin d'½il>
Cela confirme ce que je disais. Tu cherches une fonction « pour les nuls » (je dis ça sans aucune intention péjorative, exactement comme la collection de bouquins du même nom, ou comme le site du zéro).
Mais pas du tout. Quel est l'interet de demander à l'utilisateur de la fonction mail de gérer ca ? Par exemple, quand tu utilises des sockets pour gérer une connection TCP, tu fournis à la socket les données que tu veux envoyer, tu ne t'occupes pas de savoir comment en interne TCP va découper les données en paquets, ajouter un header, encapsuler ca dans de l'IP et tout. Tu fournis les données à envoyer et c'est la fonction appelée qui encode ca dans le format qu'elle veut.
Excellent exemple. Quand tu utilises TCP pour implémenter, par exemple, TELNET, tu n'as pas besoin de savoir comment fonctionne TCP, mais c'est à toi de savoir comment marche TELNET.
Ici, c'est la même chose, en remplaçant « TCP » par « SMTP » (RFC 2821), et « TELNET » par « Internet Message Format » (RFC 2822).
La fonction mail() de PHP ne s'occupe *que* du RFC 2821, et c'est à l'utilisateur de connaître le RFC 2822 (plus tous ceux qui se sont greffés par dessus et que SMTP n'a pas à connaître). Si tu veux des fonctions qui te prennent par la main pour cacher les détails du RFC 2822, alors tu vas voir ailleurs : la fonction mail() n'est pas faite pour ça.
Le fait que tu puisse passer des headers dans le champs subject plutot que le champs additional_header est un bug, ca ne rend pas la fonction plus puissante.
Tu ne sembles pas avoir compris ce que je disais, à savoir qu'un n *peut* *légitimement* apparaître dans un champ Subject, et de plus que l'interdire serait appliquer un emplâtre sur une jambe de bois puisque le détournement de cette fonction pour spammer peut se faire ailleurs que dans ce champ.
Quelqu'un qui utilise ca consciemment cherche les problemes. Si tu veux rajouter des headers supplémentaires, utilises additional_headers.
Je n'ai jamais prétendu le contraire. Merci de relire si ce n'est pas évident pour toi (Hint: FWS).
Cordialement, -- Olivier Miakinen
Vincent Lascaux
Tes sockets te fournissent des fonctionalités brutes: connexion, envoie d'octets dans l'ordre.
Pour des sockets TCP (pour des sockets UDP par exemple, le "dans l'ordre" est pas necessaire). Les sockets TCP me fournissent toute l'assurance du protocole TCP (détection de déconnexion, gestion d'erreur...) et pour ca il y a un header TCP que je n'ai pas besoin de préciser à la fonction socket. Les données que je fournit à la fonction socket ne sont pas des données brutes. Ce sont les données qui iront dans la couche TCP, pas encodées selon la RFC de TCP.
J'attends la même chose de la fonction mail : qu'on lui fournisse des données qui n'ont pas besoin d'être encodées selon la RFC de l'email.
Il te reste tout le développement de la réception de tes messages (qui peuvent être splittés sur plusieurs recv()).
Pareil, recv fait tout le boulot pour moi. Il réorganise les message dans l'ordre, vire le header TCP... pour me fournir les données "décodées". J'ai utilisé recv sans connaitre le format du header TCP.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien de TryToLog. TryToLog est responsable pour encoder $login et $pass pour pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la même raison, mail est responsable pour encoder $subject, $content de façon à pouvoir l'inserer correctement dans un email.
Donc pour une requête SQL tu acceptes de "faire ton boulot" mais pour l'envoi de mail tu veux te décharger complètement sur mail() ?
Mais non ! mysql_query prend en argument une requete SQL. J'accepte donc de faire le boulot de lui fournir une requete SQL valide. TryToLog prend en argument un login et un mot de passe. Tout login et tout mot de passe est valide. Si le login du gars est "D'Avignon", je veux fournir "D'Avignon" à TryToLog (parceque je n'ai pas à savoir ce que TryToLog va faire en interne). Il se trouve qu'en interne, TryToLog a besoin de construire une requete SQL, il doit alors encoder les arguments au format "requête SQL".
La fonction mail prend en argument un sujet. C'est à cette fonction d'encoder ce sujet pour que ca tienne dans le format du header de mail. Pas à l'appelant.
Pour moi, TryToLog et mail sont toutes les deux des fonction buggées de la même façon : elles utilisent leur paramètre dans un context où un certain encodage est nécessaire, sans réaliser cet encodage.
Pour moi, les deux cas sont mine de rien assez proche: fonction avec des risques intrinsèques connus qu'il faut traiter en amont.
Mais non, justement, TryToLog était là pour montrer que c'est DANS TryToLog qu'on s'attend à encoder les parametres pour les mettre dans la requête SQL, pas en amont. Tout comme c'est DANS mail qu'on doit encoder le sujet pour respecter ce que la RFC de l'email (et s'il veut plusieurs lignes on ne peut pas l'encoder donc on retourne false).
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce que mail "permet" dans ce bug à part la possibilité d'avoir des injections ?
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se taper un validateur de format de mail, d'alourdir le développement et du coup de casser des applications qui fonctionnent dans un contexte particulier en suivant le comportement spécifié de mail().
Si on rajoute un truc qui retourne false s'il y a un n dans le sujet, quelles sont les applications qui vont casser ? Tu dis qu'on va casser des applications qui suivent le comportement spécifié de mail(), mais la doc dit "Il [le sujet] ne doit comporter aucun caractère de nouvelle ligne"
-- Vincent
Tes sockets te fournissent des fonctionalités brutes: connexion, envoie
d'octets dans l'ordre.
Pour des sockets TCP (pour des sockets UDP par exemple, le "dans l'ordre"
est pas necessaire).
Les sockets TCP me fournissent toute l'assurance du protocole TCP (détection
de déconnexion, gestion d'erreur...) et pour ca il y a un header TCP que je
n'ai pas besoin de préciser à la fonction socket. Les données que je fournit
à la fonction socket ne sont pas des données brutes. Ce sont les données qui
iront dans la couche TCP, pas encodées selon la RFC de TCP.
J'attends la même chose de la fonction mail : qu'on lui fournisse des
données qui n'ont pas besoin d'être encodées selon la RFC de l'email.
Il te reste tout le développement de la réception de tes messages (qui
peuvent être splittés sur plusieurs recv()).
Pareil, recv fait tout le boulot pour moi. Il réorganise les message dans
l'ordre, vire le header TCP... pour me fournir les données "décodées". J'ai
utilisé recv sans connaitre le format du header TCP.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais
bien de TryToLog. TryToLog est responsable pour encoder $login et $pass
pour pouvoir l'inserer correctement dans une requete SQL. Et exactement
pour la même raison, mail est responsable pour encoder $subject, $content
de façon à pouvoir l'inserer correctement dans un email.
Donc pour une requête SQL tu acceptes de "faire ton boulot" mais pour
l'envoi de mail tu veux te décharger complètement sur mail() ?
Mais non ! mysql_query prend en argument une requete SQL. J'accepte donc de
faire le boulot de lui fournir une requete SQL valide.
TryToLog prend en argument un login et un mot de passe. Tout login et tout
mot de passe est valide. Si le login du gars est "D'Avignon", je veux
fournir "D'Avignon" à TryToLog (parceque je n'ai pas à savoir ce que
TryToLog va faire en interne). Il se trouve qu'en interne, TryToLog a besoin
de construire une requete SQL, il doit alors encoder les arguments au format
"requête SQL".
La fonction mail prend en argument un sujet. C'est à cette fonction
d'encoder ce sujet pour que ca tienne dans le format du header de mail. Pas
à l'appelant.
Pour moi, TryToLog et mail sont toutes les deux des fonction buggées de la
même façon : elles utilisent leur paramètre dans un context où un certain
encodage est nécessaire, sans réaliser cet encodage.
Pour moi, les deux cas sont mine de rien assez proche: fonction avec des
risques intrinsèques connus qu'il faut traiter en amont.
Mais non, justement, TryToLog était là pour montrer que c'est DANS TryToLog
qu'on s'attend à encoder les parametres pour les mettre dans la requête SQL,
pas en amont. Tout comme c'est DANS mail qu'on doit encoder le sujet pour
respecter ce que la RFC de l'email (et s'il veut plusieurs lignes on ne peut
pas l'encoder donc on retourne false).
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est
ce que mail "permet" dans ce bug à part la possibilité d'avoir des
injections ?
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se
taper un validateur de format de mail, d'alourdir le développement et du
coup de casser des applications qui fonctionnent dans un contexte
particulier en suivant le comportement spécifié de mail().
Si on rajoute un truc qui retourne false s'il y a un n dans le sujet,
quelles sont les applications qui vont casser ? Tu dis qu'on va casser des
applications qui suivent le comportement spécifié de mail(), mais la doc dit
"Il [le sujet] ne doit comporter aucun caractère de nouvelle ligne"
Tes sockets te fournissent des fonctionalités brutes: connexion, envoie d'octets dans l'ordre.
Pour des sockets TCP (pour des sockets UDP par exemple, le "dans l'ordre" est pas necessaire). Les sockets TCP me fournissent toute l'assurance du protocole TCP (détection de déconnexion, gestion d'erreur...) et pour ca il y a un header TCP que je n'ai pas besoin de préciser à la fonction socket. Les données que je fournit à la fonction socket ne sont pas des données brutes. Ce sont les données qui iront dans la couche TCP, pas encodées selon la RFC de TCP.
J'attends la même chose de la fonction mail : qu'on lui fournisse des données qui n'ont pas besoin d'être encodées selon la RFC de l'email.
Il te reste tout le développement de la réception de tes messages (qui peuvent être splittés sur plusieurs recv()).
Pareil, recv fait tout le boulot pour moi. Il réorganise les message dans l'ordre, vire le header TCP... pour me fournir les données "décodées". J'ai utilisé recv sans connaitre le format du header TCP.
Je ne parlais pas de mysql_query quand je disais "cette fonction", mais bien de TryToLog. TryToLog est responsable pour encoder $login et $pass pour pouvoir l'inserer correctement dans une requete SQL. Et exactement pour la même raison, mail est responsable pour encoder $subject, $content de façon à pouvoir l'inserer correctement dans un email.
Donc pour une requête SQL tu acceptes de "faire ton boulot" mais pour l'envoi de mail tu veux te décharger complètement sur mail() ?
Mais non ! mysql_query prend en argument une requete SQL. J'accepte donc de faire le boulot de lui fournir une requete SQL valide. TryToLog prend en argument un login et un mot de passe. Tout login et tout mot de passe est valide. Si le login du gars est "D'Avignon", je veux fournir "D'Avignon" à TryToLog (parceque je n'ai pas à savoir ce que TryToLog va faire en interne). Il se trouve qu'en interne, TryToLog a besoin de construire une requete SQL, il doit alors encoder les arguments au format "requête SQL".
La fonction mail prend en argument un sujet. C'est à cette fonction d'encoder ce sujet pour que ca tienne dans le format du header de mail. Pas à l'appelant.
Pour moi, TryToLog et mail sont toutes les deux des fonction buggées de la même façon : elles utilisent leur paramètre dans un context où un certain encodage est nécessaire, sans réaliser cet encodage.
Pour moi, les deux cas sont mine de rien assez proche: fonction avec des risques intrinsèques connus qu'il faut traiter en amont.
Mais non, justement, TryToLog était là pour montrer que c'est DANS TryToLog qu'on s'attend à encoder les parametres pour les mettre dans la requête SQL, pas en amont. Tout comme c'est DANS mail qu'on doit encoder le sujet pour respecter ce que la RFC de l'email (et s'il veut plusieurs lignes on ne peut pas l'encoder donc on retourne false).
Mais là c'est pas permissif, c'est buggé, il y a une différence. Qu'est ce que mail "permet" dans ce bug à part la possibilité d'avoir des injections ?
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se taper un validateur de format de mail, d'alourdir le développement et du coup de casser des applications qui fonctionnent dans un contexte particulier en suivant le comportement spécifié de mail().
Si on rajoute un truc qui retourne false s'il y a un n dans le sujet, quelles sont les applications qui vont casser ? Tu dis qu'on va casser des applications qui suivent le comportement spécifié de mail(), mais la doc dit "Il [le sujet] ne doit comporter aucun caractère de nouvelle ligne"
-- Vincent
Vincent Lascaux
function minimal_mail($msg) { system("sendmail<<$msg"); /* je sur-simplifie la lecture de stdin */ }
Cette implémentation me semble parfaitement légitime. La doc indiquerait "$msg contient un message respectant la RFC", et tu dois respecter ca.
Une fonction à peine plus évoluée, séparant entêtes et contenu du message, serait :
Je suis pas sur que cette fonction soit légitime : la RFC de mail indique que le corps doit être encodé pour n'avoir pas plus de 78 caracteres par lignes il me semble (mais je me trompe peut être). raw_mail prend en argument le corps du message. C'est à raw_mail à le formatter pour que ca respecte la RFC.
Rien à redire sur le $headers
Pour économiser quelques secondes de programmation, la fonction proposée par PHP est :
function mail($to, $subject, $message, $additional_headers) { $msg = "To: $to" . "n" . "Subject: $subject"; $msg .= "n" . $additional_headers; $msg .= "nn" . $message; minimal_mail($msg); }
Même remarques pour $to, $subject et $message.
Quant à une fonction sécurisée et orientée utilisateur, permettant d'éviter de servir de relais de spam, permettant aussi de contrôler que les adresses sont bien formées et qu'il y a un Content-Type dès qu'un caractère non-ASCII est présent, permettant aussi d'inclure des parties en HTML ou des fichiers joints binaires, cette fonction prendrait un nombre inconsidéré de paramètres et consisterait en quelques milliers de lignes de code. Ce genre de choses existe, mais ce n'est *pas* la fonction mail().
Ce n'est effectivement pas l'étendue de la fonction mail qui devrait se contenter de faire ce qu'elle déclare qu'elle fait : envoyer un email avec le corps et le sujet fournit. Si le client veut indiquer que le corps doit être interprété comme de l'HTML et pas comme du texte, c'est à lui d'ajouter les headers, on est d'accord.
Excellent exemple. Quand tu utilises TCP pour implémenter, par exemple, TELNET, tu n'as pas besoin de savoir comment fonctionne TCP, mais c'est à toi de savoir comment marche TELNET.
Ici, c'est la même chose, en remplaçant « TCP » par « SMTP » (RFC 2821), et « TELNET » par « Internet Message Format » (RFC 2822).
La fonction mail() de PHP ne s'occupe *que* du RFC 2821, et c'est à l'utilisateur de connaître le RFC 2822 (plus tous ceux qui se sont greffés par dessus et que SMTP n'a pas à connaître). Si tu veux des fonctions qui te prennent par la main pour cacher les détails du RFC 2822, alors tu vas voir ailleurs : la fonction mail() n'est pas faite pour ça.
Ah, c'est un point interessant. Dans ce cas on est d'accord. Le probleme c'est que la fonction mail prend en argument subject et content qui ne veulent dire quelque chose *que* dans le context de la RFC 2822. Ce que tu décris c'est ta fonction minimal_mail contre laquelle je n'ai rien...
Le fait que tu puisse passer des headers dans le champs subject plutot que le champs additional_header est un bug, ca ne rend pas la fonction plus puissante.
Tu ne sembles pas avoir compris ce que je disais, à savoir qu'un n *peut* *légitimement* apparaître dans un champ Subject
S'il n'y avait pas d'existant, je serais enclin à ce que mail refuse les sujets qui contiennent un n, même légitime selon la RFC 2822. Dans un code PHP, le "n" désigne un retour chariot. Si je demande l'envoit d'un email avec un n dans le sujet, je m'attends à ce que mail envoit un email dont le sujet contient plusieurs lignes. Or ceci n'est pas possible. Je sais que dans la RFC, le sujet peut être splitté sur plusieurs lignes au moyen de la chaine "n ". Ca ne veut pas dire néanmoins que la chaine représente un sujet multi lignes, mais juste que l'encodage se fait sur plusieurs lignes.
La RFC est claire sur l'équivalence des deux représentations : "Subject: This is a test
can be represented as:
Subject: This is a test"
Dans les deux cas, le sujet de l'email envoyé est "This is a test" (et n'est pas multi ligne).
et de plus que l'interdire serait appliquer un emplâtre sur une jambe de bois puisque le détournement de cette fonction pour spammer peut se faire ailleurs que dans ce champ.
Dans quel autre champ ? Si j'utilise le champ additional_headers, je vais faire bien attention à construire des headers bien formattés, parceque je sais que le champs respecte
Je n'ai jamais prétendu le contraire. Merci de relire si ce n'est pas évident pour toi (Hint: FWS).
Encore une fois, FWS est un truc interne à la RFC 2822 et $subject ne devrait pas devoir être encodé selon cette RFC quand je fais appel mail (tout comme je n'encode pas mes données pour que ca puisse aller dans un paquet TCP quand j'utilise des sockets)
-- Vincent
function minimal_mail($msg)
{
system("sendmail<<$msg"); /* je sur-simplifie la lecture de stdin */
}
Cette implémentation me semble parfaitement légitime. La doc indiquerait
"$msg contient un message respectant la RFC", et tu dois respecter ca.
Une fonction à peine plus évoluée, séparant entêtes et contenu du
message, serait :
Je suis pas sur que cette fonction soit légitime : la RFC de mail indique
que le corps doit être encodé pour n'avoir pas plus de 78 caracteres par
lignes il me semble (mais je me trompe peut être). raw_mail prend en
argument le corps du message. C'est à raw_mail à le formatter pour que ca
respecte la RFC.
Rien à redire sur le $headers
Pour économiser quelques secondes de programmation, la fonction proposée
par PHP est :
function mail($to, $subject, $message, $additional_headers)
{
$msg = "To: $to" . "n" . "Subject: $subject";
$msg .= "n" . $additional_headers;
$msg .= "nn" . $message;
minimal_mail($msg);
}
Même remarques pour $to, $subject et $message.
Quant à une fonction sécurisée et orientée utilisateur, permettant
d'éviter de servir de relais de spam, permettant aussi de contrôler que
les adresses sont bien formées et qu'il y a un Content-Type dès qu'un
caractère non-ASCII est présent, permettant aussi d'inclure des parties
en HTML ou des fichiers joints binaires, cette fonction prendrait un
nombre inconsidéré de paramètres et consisterait en quelques milliers
de lignes de code. Ce genre de choses existe, mais ce n'est *pas* la
fonction mail().
Ce n'est effectivement pas l'étendue de la fonction mail qui devrait se
contenter de faire ce qu'elle déclare qu'elle fait : envoyer un email avec
le corps et le sujet fournit. Si le client veut indiquer que le corps doit
être interprété comme de l'HTML et pas comme du texte, c'est à lui d'ajouter
les headers, on est d'accord.
Excellent exemple. Quand tu utilises TCP pour implémenter, par exemple,
TELNET, tu n'as pas besoin de savoir comment fonctionne TCP, mais c'est
à toi de savoir comment marche TELNET.
Ici, c'est la même chose, en remplaçant « TCP » par « SMTP » (RFC 2821),
et « TELNET » par « Internet Message Format » (RFC 2822).
La fonction mail() de PHP ne s'occupe *que* du RFC 2821, et c'est à
l'utilisateur de connaître le RFC 2822 (plus tous ceux qui se sont
greffés par dessus et que SMTP n'a pas à connaître). Si tu veux des
fonctions qui te prennent par la main pour cacher les détails du RFC
2822, alors tu vas voir ailleurs : la fonction mail() n'est pas faite
pour ça.
Ah, c'est un point interessant. Dans ce cas on est d'accord. Le probleme
c'est que la fonction mail prend en argument subject et content qui ne
veulent dire quelque chose *que* dans le context de la RFC 2822.
Ce que tu décris c'est ta fonction minimal_mail contre laquelle je n'ai
rien...
Le fait que tu puisse passer des headers dans le champs subject plutot
que
le champs additional_header est un bug, ca ne rend pas la fonction plus
puissante.
Tu ne sembles pas avoir compris ce que je disais, à savoir qu'un n
*peut* *légitimement* apparaître dans un champ Subject
S'il n'y avait pas d'existant, je serais enclin à ce que mail refuse les
sujets qui contiennent un n, même légitime selon la RFC 2822. Dans un code
PHP, le "n" désigne un retour chariot. Si je demande l'envoit d'un email
avec un n dans le sujet, je m'attends à ce que mail envoit un email dont le
sujet contient plusieurs lignes. Or ceci n'est pas possible. Je sais que
dans la RFC, le sujet peut être splitté sur plusieurs lignes au moyen de la
chaine "n ". Ca ne veut pas dire néanmoins que la chaine représente un
sujet multi lignes, mais juste que l'encodage se fait sur plusieurs lignes.
La RFC est claire sur l'équivalence des deux représentations :
"Subject: This is a test
can be represented as:
Subject: This
is a test"
Dans les deux cas, le sujet de l'email envoyé est "This is a test" (et n'est
pas multi ligne).
et de plus que
l'interdire serait appliquer un emplâtre sur une jambe de bois puisque
le détournement de cette fonction pour spammer peut se faire ailleurs
que dans ce champ.
Dans quel autre champ ?
Si j'utilise le champ additional_headers, je vais faire bien attention à
construire des headers bien formattés, parceque je sais que le champs
respecte
Je n'ai jamais prétendu le contraire. Merci de relire si ce n'est pas
évident pour toi (Hint: FWS).
Encore une fois, FWS est un truc interne à la RFC 2822 et $subject ne
devrait pas devoir être encodé selon cette RFC quand je fais appel mail
(tout comme je n'encode pas mes données pour que ca puisse aller dans un
paquet TCP quand j'utilise des sockets)
Je suis pas sur que cette fonction soit légitime : la RFC de mail indique que le corps doit être encodé pour n'avoir pas plus de 78 caracteres par lignes il me semble (mais je me trompe peut être). raw_mail prend en argument le corps du message. C'est à raw_mail à le formatter pour que ca respecte la RFC.
Rien à redire sur le $headers
Pour économiser quelques secondes de programmation, la fonction proposée par PHP est :
function mail($to, $subject, $message, $additional_headers) { $msg = "To: $to" . "n" . "Subject: $subject"; $msg .= "n" . $additional_headers; $msg .= "nn" . $message; minimal_mail($msg); }
Même remarques pour $to, $subject et $message.
Quant à une fonction sécurisée et orientée utilisateur, permettant d'éviter de servir de relais de spam, permettant aussi de contrôler que les adresses sont bien formées et qu'il y a un Content-Type dès qu'un caractère non-ASCII est présent, permettant aussi d'inclure des parties en HTML ou des fichiers joints binaires, cette fonction prendrait un nombre inconsidéré de paramètres et consisterait en quelques milliers de lignes de code. Ce genre de choses existe, mais ce n'est *pas* la fonction mail().
Ce n'est effectivement pas l'étendue de la fonction mail qui devrait se contenter de faire ce qu'elle déclare qu'elle fait : envoyer un email avec le corps et le sujet fournit. Si le client veut indiquer que le corps doit être interprété comme de l'HTML et pas comme du texte, c'est à lui d'ajouter les headers, on est d'accord.
Excellent exemple. Quand tu utilises TCP pour implémenter, par exemple, TELNET, tu n'as pas besoin de savoir comment fonctionne TCP, mais c'est à toi de savoir comment marche TELNET.
Ici, c'est la même chose, en remplaçant « TCP » par « SMTP » (RFC 2821), et « TELNET » par « Internet Message Format » (RFC 2822).
La fonction mail() de PHP ne s'occupe *que* du RFC 2821, et c'est à l'utilisateur de connaître le RFC 2822 (plus tous ceux qui se sont greffés par dessus et que SMTP n'a pas à connaître). Si tu veux des fonctions qui te prennent par la main pour cacher les détails du RFC 2822, alors tu vas voir ailleurs : la fonction mail() n'est pas faite pour ça.
Ah, c'est un point interessant. Dans ce cas on est d'accord. Le probleme c'est que la fonction mail prend en argument subject et content qui ne veulent dire quelque chose *que* dans le context de la RFC 2822. Ce que tu décris c'est ta fonction minimal_mail contre laquelle je n'ai rien...
Le fait que tu puisse passer des headers dans le champs subject plutot que le champs additional_header est un bug, ca ne rend pas la fonction plus puissante.
Tu ne sembles pas avoir compris ce que je disais, à savoir qu'un n *peut* *légitimement* apparaître dans un champ Subject
S'il n'y avait pas d'existant, je serais enclin à ce que mail refuse les sujets qui contiennent un n, même légitime selon la RFC 2822. Dans un code PHP, le "n" désigne un retour chariot. Si je demande l'envoit d'un email avec un n dans le sujet, je m'attends à ce que mail envoit un email dont le sujet contient plusieurs lignes. Or ceci n'est pas possible. Je sais que dans la RFC, le sujet peut être splitté sur plusieurs lignes au moyen de la chaine "n ". Ca ne veut pas dire néanmoins que la chaine représente un sujet multi lignes, mais juste que l'encodage se fait sur plusieurs lignes.
La RFC est claire sur l'équivalence des deux représentations : "Subject: This is a test
can be represented as:
Subject: This is a test"
Dans les deux cas, le sujet de l'email envoyé est "This is a test" (et n'est pas multi ligne).
et de plus que l'interdire serait appliquer un emplâtre sur une jambe de bois puisque le détournement de cette fonction pour spammer peut se faire ailleurs que dans ce champ.
Dans quel autre champ ? Si j'utilise le champ additional_headers, je vais faire bien attention à construire des headers bien formattés, parceque je sais que le champs respecte
Je n'ai jamais prétendu le contraire. Merci de relire si ce n'est pas évident pour toi (Hint: FWS).
Encore une fois, FWS est un truc interne à la RFC 2822 et $subject ne devrait pas devoir être encodé selon cette RFC quand je fais appel mail (tout comme je n'encode pas mes données pour que ca puisse aller dans un paquet TCP quand j'utilise des sockets)
-- Vincent
Olivier Miakinen
Le 01/07/2006 22:29, Vincent Lascaux répondait à Calimero :
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se taper un validateur de format de mail, d'alourdir le développement et du coup de casser des applications qui fonctionnent dans un contexte particulier en suivant le comportement spécifié de mail().
D'autant plus que ces surcouches de mail() non limitées à RFC 2821 mais incluant RFC 2822 ainsi que les RFC 2045 à 2049, il en existe. Par exemple PEAR::Mail et PEAR::Mail_Mime qu'on trouve cités dans la section « Voir aussi » de <http://fr.php.net/manual/fr/function.mail.php>.
Si on rajoute un truc qui retourne false s'il y a un n dans le sujet,
... c'est-à-dire si l'on tente de rajouter 0,01 % du chemin qui sépare mail() de ses surcouches ...
quelles sont les applications qui vont casser ?
Par exemple celles qui doivent encoder un sujet d'une trentaine de caractères en japonais (eh oui, tout le monde n'utilise pas des caractères latins), chaque caractère occupant 2 octets en Shift-JIS (trois en UTF-8 si je ne m'abuse), ce qui fait donc 60 octets (ou 90), soit au minimum 80 octets en Base64, plus les petits grigris indiquant l'encodage, sans compter le mot-clé « Subject: ». Bref, pour un titre de seulement 30 caractères, on dépasse la limite recommandée de 78 caractères par ligne, et l'emploi d'un FWS est normal.
Tu dis qu'on va casser des applications qui suivent le comportement spécifié de mail(), mais la doc dit "Il [le sujet] ne doit comporter aucun caractère de nouvelle ligne"
Tu peux ouvrir un rapport de bug sur la doc si tu veux, mais je te souhaite bien du courage pour résumer en quelques lignes tout ce qu'il faut savoir de l'« Internet Message Format ».
Le 01/07/2006 22:29, Vincent Lascaux répondait à Calimero :
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se
taper un validateur de format de mail, d'alourdir le développement et du
coup de casser des applications qui fonctionnent dans un contexte
particulier en suivant le comportement spécifié de mail().
D'autant plus que ces surcouches de mail() non limitées à RFC 2821 mais
incluant RFC 2822 ainsi que les RFC 2045 à 2049, il en existe. Par
exemple PEAR::Mail et PEAR::Mail_Mime qu'on trouve cités dans la section
« Voir aussi » de <http://fr.php.net/manual/fr/function.mail.php>.
Si on rajoute un truc qui retourne false s'il y a un n dans le sujet,
... c'est-à-dire si l'on tente de rajouter 0,01 % du chemin qui sépare
mail() de ses surcouches ...
quelles sont les applications qui vont casser ?
Par exemple celles qui doivent encoder un sujet d'une trentaine de
caractères en japonais (eh oui, tout le monde n'utilise pas des
caractères latins), chaque caractère occupant 2 octets en Shift-JIS
(trois en UTF-8 si je ne m'abuse), ce qui fait donc 60 octets (ou 90),
soit au minimum 80 octets en Base64, plus les petits grigris indiquant
l'encodage, sans compter le mot-clé « Subject: ». Bref, pour un titre
de seulement 30 caractères, on dépasse la limite recommandée de 78
caractères par ligne, et l'emploi d'un FWS est normal.
Tu dis qu'on va casser des
applications qui suivent le comportement spécifié de mail(), mais la doc dit
"Il [le sujet] ne doit comporter aucun caractère de nouvelle ligne"
Tu peux ouvrir un rapport de bug sur la doc si tu veux, mais je te
souhaite bien du courage pour résumer en quelques lignes tout ce qu'il
faut savoir de l'« Internet Message Format ».
Le 01/07/2006 22:29, Vincent Lascaux répondait à Calimero :
J'aurais tendance à dire que l'équipe PHP a autre chose à faire que se taper un validateur de format de mail, d'alourdir le développement et du coup de casser des applications qui fonctionnent dans un contexte particulier en suivant le comportement spécifié de mail().
D'autant plus que ces surcouches de mail() non limitées à RFC 2821 mais incluant RFC 2822 ainsi que les RFC 2045 à 2049, il en existe. Par exemple PEAR::Mail et PEAR::Mail_Mime qu'on trouve cités dans la section « Voir aussi » de <http://fr.php.net/manual/fr/function.mail.php>.
Si on rajoute un truc qui retourne false s'il y a un n dans le sujet,
... c'est-à-dire si l'on tente de rajouter 0,01 % du chemin qui sépare mail() de ses surcouches ...
quelles sont les applications qui vont casser ?
Par exemple celles qui doivent encoder un sujet d'une trentaine de caractères en japonais (eh oui, tout le monde n'utilise pas des caractères latins), chaque caractère occupant 2 octets en Shift-JIS (trois en UTF-8 si je ne m'abuse), ce qui fait donc 60 octets (ou 90), soit au minimum 80 octets en Base64, plus les petits grigris indiquant l'encodage, sans compter le mot-clé « Subject: ». Bref, pour un titre de seulement 30 caractères, on dépasse la limite recommandée de 78 caractères par ligne, et l'emploi d'un FWS est normal.
Tu dis qu'on va casser des applications qui suivent le comportement spécifié de mail(), mais la doc dit "Il [le sujet] ne doit comporter aucun caractère de nouvelle ligne"
Tu peux ouvrir un rapport de bug sur la doc si tu veux, mais je te souhaite bien du courage pour résumer en quelques lignes tout ce qu'il faut savoir de l'« Internet Message Format ».
