J'utilise PHP version 5.2.6
Mon script de recuperation de données d'un formulaire ne recupere rien.
Il m'envoie bien un mail mais vide. Voici le contenu du mail que je reçois:
echo "<HTML><HEAD>";
echo "<TITLE>Formulaire envoyer!</TITLE></HEAD><BODY>";
echo "<H1 align=center>Merci, $nom </H1>";
echo "<P align=center>";
echo "Votre formulaire à bien été envoyé !</P>";
echo "</BODY></HTML>";
?>
Merci de m'aider à corriger mon script "envoi.php" pour qu'il recupère
effectivement les données de mon formulaire. Est-ce un problème de
paramettrage
du fichier PHP.ini ? Si oui, quel paramètre à modifier?
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
C'est que tu n'as pas compris la différence sémantique entre HTTP GET et HTTP POST, ni les implications en terme de sécurité que cela implique.
La diférence sémantique entre GET et POST aura une importance le jour on on aura aussi PUT, DELETE et CONNECT. Pour l'instant, très peu de REST à l'horizon :)
Hélas... Mais bon, la différence n'en reste pas moins réelle du point de vue sémantique, et vu l'ignorance moyenne du protocole http par les développeurs web, il n'est pas forcément inutile de la rappeler (la différence...) - même si l'argument de la sécurité est effectivement ici plus que discutable.
Quant aux implications en termes de sécurité, qu'une donnée arrive par GET ou POST, il faut qu'elle soit validée (à coup de filter ou autre) et à partir de là, utiliser GET&POST / REQUEST n'a plus trop d'importance.
Là encore, ça ne fait en effet guère de différence du point de vue de la sécurité. Par contre, utiliser explicitement $_GET ou $_POST (ou $_COOKIE etc) permet de 1/ documenter ce qui est attendu et 2/ de détecter plus facilement des horreurs tels que des liens (GET) sur une action non idempotente. Bref, si ça ne change rien du point de vue de la sécurité, ça peut au moins avoir un impact sur la lisibilité du code, la robustesse de l'application, et l'éducation des développeurs...
(snip)
Freddy DISSAUX a écrit :
Le 22 Sep 2008 14:05:45 GMT, Mickaël écrivait:
Freddy DISSAUX a écrit :
Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.
C'est que tu n'as pas compris la différence sémantique entre HTTP GET
et HTTP POST, ni les implications en terme de sécurité que cela implique.
La diférence sémantique entre GET et POST aura une importance le jour on
on aura aussi PUT, DELETE et CONNECT. Pour l'instant, très peu de REST à
l'horizon :)
Hélas... Mais bon, la différence n'en reste pas moins réelle du point de
vue sémantique, et vu l'ignorance moyenne du protocole http par les
développeurs web, il n'est pas forcément inutile de la rappeler (la
différence...) - même si l'argument de la sécurité est effectivement ici
plus que discutable.
Quant aux implications en termes de sécurité, qu'une donnée arrive par
GET ou POST, il faut qu'elle soit validée (à coup de filter ou autre)
et à partir de là, utiliser GET&POST / REQUEST n'a plus trop
d'importance.
Là encore, ça ne fait en effet guère de différence du point de vue de la
sécurité. Par contre, utiliser explicitement $_GET ou $_POST (ou
$_COOKIE etc) permet de 1/ documenter ce qui est attendu et 2/ de
détecter plus facilement des horreurs tels que des liens (GET) sur une
action non idempotente. Bref, si ça ne change rien du point de vue de la
sécurité, ça peut au moins avoir un impact sur la lisibilité du code, la
robustesse de l'application, et l'éducation des développeurs...
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
C'est que tu n'as pas compris la différence sémantique entre HTTP GET et HTTP POST, ni les implications en terme de sécurité que cela implique.
La diférence sémantique entre GET et POST aura une importance le jour on on aura aussi PUT, DELETE et CONNECT. Pour l'instant, très peu de REST à l'horizon :)
Hélas... Mais bon, la différence n'en reste pas moins réelle du point de vue sémantique, et vu l'ignorance moyenne du protocole http par les développeurs web, il n'est pas forcément inutile de la rappeler (la différence...) - même si l'argument de la sécurité est effectivement ici plus que discutable.
Quant aux implications en termes de sécurité, qu'une donnée arrive par GET ou POST, il faut qu'elle soit validée (à coup de filter ou autre) et à partir de là, utiliser GET&POST / REQUEST n'a plus trop d'importance.
Là encore, ça ne fait en effet guère de différence du point de vue de la sécurité. Par contre, utiliser explicitement $_GET ou $_POST (ou $_COOKIE etc) permet de 1/ documenter ce qui est attendu et 2/ de détecter plus facilement des horreurs tels que des liens (GET) sur une action non idempotente. Bref, si ça ne change rien du point de vue de la sécurité, ça peut au moins avoir un impact sur la lisibilité du code, la robustesse de l'application, et l'éducation des développeurs...
(snip)
Antoine
Patrick Mevzek wrote :
Certes, et sur ce point nous sommes d'accord. Mais cela n'a donc rien à voir avec *comment* on accède à ces données, que ce soit un tableau appelé POST ou un tableau appelé GET (les données viennent de « n'importe où » dans les deux cas).
Merci pour toutes explications.
Si on résume : en termes de sécurité, on se moque de savoir si l'appel d'un script est en POST ou en GET, ce qui compte c'est le contrôle des données en entrée (nombre, type, valeur) en absolu d'une part et relativement à l'environnement courant (utilisateur identifié, etc) d'autre part, non ?
-- Antoine
Patrick Mevzek <pm-N200809@nospam.dotandco.com> wrote :
Certes, et sur ce point nous sommes d'accord. Mais cela n'a donc
rien à voir avec *comment* on accède à ces données, que ce soit un
tableau appelé POST ou un tableau appelé GET (les données viennent
de « n'importe où » dans les deux cas).
Merci pour toutes explications.
Si on résume : en termes de sécurité, on se moque de savoir si
l'appel d'un script est en POST ou en GET, ce qui compte c'est le
contrôle des données en entrée (nombre, type, valeur) en absolu
d'une part et relativement à l'environnement courant (utilisateur
identifié, etc) d'autre part, non ?
Certes, et sur ce point nous sommes d'accord. Mais cela n'a donc rien à voir avec *comment* on accède à ces données, que ce soit un tableau appelé POST ou un tableau appelé GET (les données viennent de « n'importe où » dans les deux cas).
Merci pour toutes explications.
Si on résume : en termes de sécurité, on se moque de savoir si l'appel d'un script est en POST ou en GET, ce qui compte c'est le contrôle des données en entrée (nombre, type, valeur) en absolu d'une part et relativement à l'environnement courant (utilisateur identifié, etc) d'autre part, non ?
-- Antoine
Michael DENIS
Patrick Mevzek a écrit :
Ce n'est pas la façon dont une variable est transportée qui doit déterminer une mesure de sécurité.
Je vous rejoins là-dessus. En revanche, si la façon dont la variable est transportée n'est pas conforme à ce qui était prévu, c'est déjà un problème avant même de savoir ce qu'elle contient. Et je pense que c'est là l'intérêt d'utiliser $_GET ou $_POST plutôt que $_REQUEST (ou de vérifier la méthode de transport). Mais ce n'est qu'une vérification supplémentaire, et, nous sommes bien d'accord, pas du tout une mesure de sécurité suffisante.
Ca serait comme dire : si je recois un courrier via Chronopost je ne le lis pas de la même façon que si je le reçois par la poste normale.
Non, ce serait comme dire: si j'attends un courrier par Chronopost et qu'il arrive par la poste normale, c'est qu'il y a une anomalie. Et avant même de savoir ce qu'il contient, je pourrais éventuellement décider de ne pas l'ouvrir (un peu bizarre dans le cas d'un courrier, mais c'est pour l'exemple :-)). C'est, encore une fois, une vérification préalable et complémentaire, pas suffisante.
-- Michaël DENIS
Patrick Mevzek a écrit :
Ce n'est pas la façon dont une variable est transportée qui doit
déterminer une mesure de sécurité.
Je vous rejoins là-dessus. En revanche, si la façon dont la variable est
transportée n'est pas conforme à ce qui était prévu, c'est déjà un
problème avant même de savoir ce qu'elle contient. Et je pense que c'est
là l'intérêt d'utiliser $_GET ou $_POST plutôt que $_REQUEST (ou de
vérifier la méthode de transport). Mais ce n'est qu'une vérification
supplémentaire, et, nous sommes bien d'accord, pas du tout une mesure de
sécurité suffisante.
Ca serait comme dire : si je recois un courrier via Chronopost je ne le
lis pas de la même façon que si je le reçois par la poste normale.
Non, ce serait comme dire: si j'attends un courrier par Chronopost et
qu'il arrive par la poste normale, c'est qu'il y a une anomalie. Et
avant même de savoir ce qu'il contient, je pourrais éventuellement
décider de ne pas l'ouvrir (un peu bizarre dans le cas d'un courrier,
mais c'est pour l'exemple :-)). C'est, encore une fois, une vérification
préalable et complémentaire, pas suffisante.
Ce n'est pas la façon dont une variable est transportée qui doit déterminer une mesure de sécurité.
Je vous rejoins là-dessus. En revanche, si la façon dont la variable est transportée n'est pas conforme à ce qui était prévu, c'est déjà un problème avant même de savoir ce qu'elle contient. Et je pense que c'est là l'intérêt d'utiliser $_GET ou $_POST plutôt que $_REQUEST (ou de vérifier la méthode de transport). Mais ce n'est qu'une vérification supplémentaire, et, nous sommes bien d'accord, pas du tout une mesure de sécurité suffisante.
Ca serait comme dire : si je recois un courrier via Chronopost je ne le lis pas de la même façon que si je le reçois par la poste normale.
Non, ce serait comme dire: si j'attends un courrier par Chronopost et qu'il arrive par la poste normale, c'est qu'il y a une anomalie. Et avant même de savoir ce qu'il contient, je pourrais éventuellement décider de ne pas l'ouvrir (un peu bizarre dans le cas d'un courrier, mais c'est pour l'exemple :-)). C'est, encore une fois, une vérification préalable et complémentaire, pas suffisante.
-- Michaël DENIS
Nicolas Krebs
Patrick Mevzek écrivit dans l'article news:49c047a3$0$24706$
Mieux vaut ne pas trop me lancer sur SPIP :-)
Quelle est votre appréciation de la mutualisation (1) de SPIP 2.0, et quelles améliorations suggérieriez vous ? http://www.spip.net/fr_article3514.html http://www.spip-contrib.net/Mutualisation http://www.spip-contrib.net/Plugin-Mutualisation
1 : équivalent du « multiblog » de Dotclear 2 ( http://fr.dotclear.org/documentation/2.0/admin/multiblog ) et et Wordpress, autres logiciels serveurs web pour lesquels vous pouvez aussi rpondre aux questions ci-dessus.
Patrick Mevzek écrivit dans l'article
news:49c047a3$0$24706$426a74cc@news.free.fr
Mieux vaut ne pas trop me lancer sur SPIP :-)
Quelle est votre appréciation de la mutualisation (1) de SPIP 2.0, et
quelles améliorations suggérieriez vous ?
http://www.spip.net/fr_article3514.html
http://www.spip-contrib.net/Mutualisation
http://www.spip-contrib.net/Plugin-Mutualisation
1 : équivalent du « multiblog » de Dotclear 2
( http://fr.dotclear.org/documentation/2.0/admin/multiblog ) et et
Wordpress, autres logiciels serveurs web pour lesquels vous pouvez aussi
rpondre aux questions ci-dessus.
Patrick Mevzek écrivit dans l'article news:49c047a3$0$24706$
Mieux vaut ne pas trop me lancer sur SPIP :-)
Quelle est votre appréciation de la mutualisation (1) de SPIP 2.0, et quelles améliorations suggérieriez vous ? http://www.spip.net/fr_article3514.html http://www.spip-contrib.net/Mutualisation http://www.spip-contrib.net/Plugin-Mutualisation
1 : équivalent du « multiblog » de Dotclear 2 ( http://fr.dotclear.org/documentation/2.0/admin/multiblog ) et et Wordpress, autres logiciels serveurs web pour lesquels vous pouvez aussi rpondre aux questions ci-dessus.
