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
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.
OK. Mais il te reste tout le boulot de reformation de tes messages à partir des suites d'octets de taille variable que tu as reçu successivement. Et ca, TCP peut pas le faire à ta place parce qu'il ne sait pas ce que tu veux faire. Pour mail, étant donné la foultitude de formats, il est trop couteux de développer un validateur de mail pour un résultat pas forcément top.
<zap sur le reste> Je comprends qu'éventuellement ca puisse "déranger" que mail() accepte l'envoi (la tentative) d'un mail mal formaté. Maintenant, mettre un filtre sur les n dans les retours à la ligne dans le sujet est une non solution comme le dit Olivier. C'est l'arbre qui cache la foret. </zap sur le reste>
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"
Tu as oublié la fin de la phrase: "sinon, le mail risque de ne pas etre envoye correctement.". Il y a donc bien tentative d'envoi du mail.
-- @+ Calimero
Vincent Lascaux wrote:
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.
OK. Mais il te reste tout le boulot de reformation de tes messages à
partir des suites d'octets de taille variable que tu as reçu
successivement. Et ca, TCP peut pas le faire à ta place parce qu'il ne
sait pas ce que tu veux faire.
Pour mail, étant donné la foultitude de formats, il est trop couteux
de développer un validateur de mail pour un résultat pas forcément top.
<zap sur le reste>
Je comprends qu'éventuellement ca puisse "déranger" que mail() accepte
l'envoi (la tentative) d'un mail mal formaté. Maintenant, mettre un
filtre sur les n dans les retours à la ligne dans le sujet est une
non solution comme le dit Olivier. C'est l'arbre qui cache la foret.
</zap sur le reste>
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"
Tu as oublié la fin de la phrase: "sinon, le mail risque de ne pas
etre envoye correctement.".
Il y a donc bien tentative d'envoi du mail.
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.
OK. Mais il te reste tout le boulot de reformation de tes messages à partir des suites d'octets de taille variable que tu as reçu successivement. Et ca, TCP peut pas le faire à ta place parce qu'il ne sait pas ce que tu veux faire. Pour mail, étant donné la foultitude de formats, il est trop couteux de développer un validateur de mail pour un résultat pas forcément top.
<zap sur le reste> Je comprends qu'éventuellement ca puisse "déranger" que mail() accepte l'envoi (la tentative) d'un mail mal formaté. Maintenant, mettre un filtre sur les n dans les retours à la ligne dans le sujet est une non solution comme le dit Olivier. C'est l'arbre qui cache la foret. </zap sur le reste>
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"
Tu as oublié la fin de la phrase: "sinon, le mail risque de ne pas etre envoye correctement.". Il y a donc bien tentative d'envoi du mail.
-- @+ Calimero
Vincent Lascaux
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 ».
Roh, on aurait du commencer par là :) http://news.php.net/article.php?group=php.cvs&article348
Donc ca serait fixé ? ils ont ajouté ca à la fonction mail. for(i=0;!iscntrl((unsigned char)subject[i]);i++) {} subject[i]=' ';
(subject est tronqué au premier caractere "iscntrl")
Ca m'apprendra à dire du mal des devs PHP ! Si tu veux ouvrir un bug pour que les FWS fonctionne... je te souhaite bien du courage aussi :)
-- Vincent
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 ».
Roh, on aurait du commencer par là :)
http://news.php.net/article.php?group=php.cvs&article348
Donc ca serait fixé ? ils ont ajouté ca à la fonction mail.
for(i=0;!iscntrl((unsigned char)subject[i]);i++) {}
subject[i]=' ';
(subject est tronqué au premier caractere "iscntrl")
Ca m'apprendra à dire du mal des devs PHP !
Si tu veux ouvrir un bug pour que les FWS fonctionne... je te souhaite bien
du courage aussi :)
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 ».
Roh, on aurait du commencer par là :) http://news.php.net/article.php?group=php.cvs&article348
Donc ca serait fixé ? ils ont ajouté ca à la fonction mail. for(i=0;!iscntrl((unsigned char)subject[i]);i++) {} subject[i]=' ';
(subject est tronqué au premier caractere "iscntrl")
Ca m'apprendra à dire du mal des devs PHP ! Si tu veux ouvrir un bug pour que les FWS fonctionne... je te souhaite bien du courage aussi :)
-- Vincent
Olivier Miakinen
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 ».
Roh, on aurait du commencer par là :) http://news.php.net/article.php?group=php.cvs&article348
Rho, on aurait même dû commencer par là :) http://lxr.php.net/source/php-src/ext/standard/mail.c
Donc ca serait fixé ? ils ont ajouté ca à la fonction mail. for(i=0;!iscntrl((unsigned char)subject[i]);i++) {} subject[i]=' ';
(subject est tronqué au premier caractere "iscntrl")
Ca m'apprendra à dire du mal des devs PHP !
;-)
Si tu veux ouvrir un bug pour que les FWS fonctionne... je te souhaite bien du courage aussi :)
Pas la peine :
for (i = 0; to_r[i]; i++) { if (iscntrl((unsigned char) to_r[i])) { /* According to RFC 822, section 3.1.1 * long headers may be separated into * parts using CRLF followed at least one * linear-white-space character ('t' or ' '). * To prevent these separators from being * replaced with a space, we use the * SKIP_LONG_HEADER_SEP to skip over them. */ SKIP_LONG_HEADER_SEP(to_r, i); to_r[i] = ' '; } }
Tout va donc pour le mieux dans le meilleur des mondes.
Bon, il reste quand même trois problèmes, à savoir : - on peut toujours mettre des champs Bcc dans additional_headers ; - ton adresse invalide n'est toujours pas terminée par .invalid ; - tu envoies toujours des articles avec accents sans déclaration MIME.
[ je propose un suivi en privé pour les deux derniers points ]
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 ».
Roh, on aurait du commencer par là :)
http://news.php.net/article.php?group=php.cvs&article348
Rho, on aurait même dû commencer par là :)
http://lxr.php.net/source/php-src/ext/standard/mail.c
Donc ca serait fixé ? ils ont ajouté ca à la fonction mail.
for(i=0;!iscntrl((unsigned char)subject[i]);i++) {}
subject[i]=' ';
(subject est tronqué au premier caractere "iscntrl")
Ca m'apprendra à dire du mal des devs PHP !
;-)
Si tu veux ouvrir un bug pour que les FWS fonctionne... je te souhaite bien
du courage aussi :)
Pas la peine :
for (i = 0; to_r[i]; i++) {
if (iscntrl((unsigned char) to_r[i])) {
/* According to RFC 822, section 3.1.1
* long headers may be separated into
* parts using CRLF followed at least one
* linear-white-space character ('t' or ' ').
* To prevent these separators from being
* replaced with a space, we use the
* SKIP_LONG_HEADER_SEP to skip over them.
*/
SKIP_LONG_HEADER_SEP(to_r, i);
to_r[i] = ' ';
}
}
Tout va donc pour le mieux dans le meilleur des mondes.
Bon, il reste quand même trois problèmes, à savoir :
- on peut toujours mettre des champs Bcc dans additional_headers ;
- ton adresse invalide n'est toujours pas terminée par .invalid ;
- tu envoies toujours des articles avec accents sans déclaration MIME.
[ je propose un suivi en privé pour les deux derniers points ]
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 ».
Roh, on aurait du commencer par là :) http://news.php.net/article.php?group=php.cvs&article348
Rho, on aurait même dû commencer par là :) http://lxr.php.net/source/php-src/ext/standard/mail.c
Donc ca serait fixé ? ils ont ajouté ca à la fonction mail. for(i=0;!iscntrl((unsigned char)subject[i]);i++) {} subject[i]=' ';
(subject est tronqué au premier caractere "iscntrl")
Ca m'apprendra à dire du mal des devs PHP !
;-)
Si tu veux ouvrir un bug pour que les FWS fonctionne... je te souhaite bien du courage aussi :)
Pas la peine :
for (i = 0; to_r[i]; i++) { if (iscntrl((unsigned char) to_r[i])) { /* According to RFC 822, section 3.1.1 * long headers may be separated into * parts using CRLF followed at least one * linear-white-space character ('t' or ' '). * To prevent these separators from being * replaced with a space, we use the * SKIP_LONG_HEADER_SEP to skip over them. */ SKIP_LONG_HEADER_SEP(to_r, i); to_r[i] = ' '; } }
Tout va donc pour le mieux dans le meilleur des mondes.
Bon, il reste quand même trois problèmes, à savoir : - on peut toujours mettre des champs Bcc dans additional_headers ; - ton adresse invalide n'est toujours pas terminée par .invalid ; - tu envoies toujours des articles avec accents sans déclaration MIME.
[ je propose un suivi en privé pour les deux derniers points ]
Vincent Lascaux
Pas la peine :
for (i = 0; to_r[i]; i++) { if (iscntrl((unsigned char) to_r[i])) { /* According to RFC 822, section 3.1.1 * long headers may be separated into * parts using CRLF followed at least one * linear-white-space character ('t' or ' '). * To prevent these separators from being * replaced with a space, we use the * SKIP_LONG_HEADER_SEP to skip over them. */ SKIP_LONG_HEADER_SEP(to_r, i); to_r[i] = ' '; } }
Etrange... ca concerne que le champ to alors que la RFC parle de tous les headers ?
Gasp, finalement je vais ptet redire du mal des codeurs PHP alors :) Un continue caché dans une macro, c'est pas mal... Ca m'a pris un peu de temps pour comprendre pourquoi le to_r[i] = ' '; était pas executé après un "rn "
- on peut toujours mettre des champs Bcc dans additional_headers ;
Oui, mais la fonction mail "décline toute responsabilité" sur ce champs. Il doit être au format spécifié par la RFC. Moi ca ne me gêne pas dans ce contexte.
-- Vincent
Pas la peine :
for (i = 0; to_r[i]; i++) {
if (iscntrl((unsigned char) to_r[i])) {
/* According to RFC 822, section 3.1.1
* long headers may be separated into
* parts using CRLF followed at least one
* linear-white-space character ('t' or ' ').
* To prevent these separators from being
* replaced with a space, we use the
* SKIP_LONG_HEADER_SEP to skip over them.
*/
SKIP_LONG_HEADER_SEP(to_r, i);
to_r[i] = ' ';
}
}
Etrange... ca concerne que le champ to alors que la RFC parle de tous les
headers ?
Gasp, finalement je vais ptet redire du mal des codeurs PHP alors :)
Un continue caché dans une macro, c'est pas mal... Ca m'a pris un peu de
temps pour comprendre pourquoi le to_r[i] = ' '; était pas executé après un
"rn "
- on peut toujours mettre des champs Bcc dans additional_headers ;
Oui, mais la fonction mail "décline toute responsabilité" sur ce champs. Il
doit être au format spécifié par la RFC. Moi ca ne me gêne pas dans ce
contexte.
for (i = 0; to_r[i]; i++) { if (iscntrl((unsigned char) to_r[i])) { /* According to RFC 822, section 3.1.1 * long headers may be separated into * parts using CRLF followed at least one * linear-white-space character ('t' or ' '). * To prevent these separators from being * replaced with a space, we use the * SKIP_LONG_HEADER_SEP to skip over them. */ SKIP_LONG_HEADER_SEP(to_r, i); to_r[i] = ' '; } }
Etrange... ca concerne que le champ to alors que la RFC parle de tous les headers ?
Gasp, finalement je vais ptet redire du mal des codeurs PHP alors :) Un continue caché dans une macro, c'est pas mal... Ca m'a pris un peu de temps pour comprendre pourquoi le to_r[i] = ' '; était pas executé après un "rn "
- on peut toujours mettre des champs Bcc dans additional_headers ;
Oui, mais la fonction mail "décline toute responsabilité" sur ce champs. Il doit être au format spécifié par la RFC. Moi ca ne me gêne pas dans ce contexte.
-- Vincent
Olivier Miakinen
Etrange... ca concerne que le champ to alors que la RFC parle de tous les headers ?
Ça concerne aussi le champ subject, mais le commentaire était ici uniquement.
Gasp, finalement je vais ptet redire du mal des codeurs PHP alors :) Un continue caché dans une macro, c'est pas mal...
Si la macro était dans un .h je serais d'accord avec toi. Mais là comme c'est spécifique au .c, il n'y a pas de risque qu'elle soit utilisée par d'autres fonctions. Une macro n'est pas une fonction : ce n'est que du pré-processing.
- on peut toujours mettre des champs Bcc dans additional_headers ;
Oui, mais la fonction mail "décline toute responsabilité" sur ce champs. Il doit être au format spécifié par la RFC. Moi ca ne me gêne pas dans ce contexte.
Ok.
<HS 1> Grand merci pour le « .invalid ». </HS 1>
<HS 2> Pour la config d'Outlook Express, voir : <http://groups.google.fr/group/fr.usenet.8bits/msg/b19ddc12c7bf7b54> </HS 2>
<HS 3> Tu n'avais rien à répondre sur le sujet « afficher sans extension » ? </HS 3>
Etrange... ca concerne que le champ to alors que la RFC parle de tous les
headers ?
Ça concerne aussi le champ subject, mais le commentaire était ici
uniquement.
Gasp, finalement je vais ptet redire du mal des codeurs PHP alors :)
Un continue caché dans une macro, c'est pas mal...
Si la macro était dans un .h je serais d'accord avec toi. Mais là comme
c'est spécifique au .c, il n'y a pas de risque qu'elle soit utilisée par
d'autres fonctions. Une macro n'est pas une fonction : ce n'est que du
pré-processing.
- on peut toujours mettre des champs Bcc dans additional_headers ;
Oui, mais la fonction mail "décline toute responsabilité" sur ce champs. Il
doit être au format spécifié par la RFC. Moi ca ne me gêne pas dans ce
contexte.
Ok.
<HS 1>
Grand merci pour le « .invalid ».
</HS 1>
<HS 2>
Pour la config d'Outlook Express, voir :
<http://groups.google.fr/group/fr.usenet.8bits/msg/b19ddc12c7bf7b54>
</HS 2>
<HS 3>
Tu n'avais rien à répondre sur le sujet « afficher sans extension » ?
</HS 3>
Etrange... ca concerne que le champ to alors que la RFC parle de tous les headers ?
Ça concerne aussi le champ subject, mais le commentaire était ici uniquement.
Gasp, finalement je vais ptet redire du mal des codeurs PHP alors :) Un continue caché dans une macro, c'est pas mal...
Si la macro était dans un .h je serais d'accord avec toi. Mais là comme c'est spécifique au .c, il n'y a pas de risque qu'elle soit utilisée par d'autres fonctions. Une macro n'est pas une fonction : ce n'est que du pré-processing.
- on peut toujours mettre des champs Bcc dans additional_headers ;
Oui, mais la fonction mail "décline toute responsabilité" sur ce champs. Il doit être au format spécifié par la RFC. Moi ca ne me gêne pas dans ce contexte.
Ok.
<HS 1> Grand merci pour le « .invalid ». </HS 1>
<HS 2> Pour la config d'Outlook Express, voir : <http://groups.google.fr/group/fr.usenet.8bits/msg/b19ddc12c7bf7b54> </HS 2>
<HS 3> Tu n'avais rien à répondre sur le sujet « afficher sans extension » ? </HS 3>
