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?
du fichier PHP.ini ? Si oui, quel paramètre à modifier?
Il y a plein de raisons de sécurité qui font que ton script ne doit pas être utilisé. Tu as de la chance de ne pas être un spammeur (à moins que tu ne le saches pas ;) Les variables HTTP POST sont disponible dans $_POST. Je t'invite à relire le manuel PHP à ce propos.
Mais surtout, je t'encourage vivement à faire une recherche à propos du détournement de formulaires.
du fichier PHP.ini ? Si oui, quel paramètre à modifier?
Il y a plein de raisons de sécurité qui font que ton script ne doit
pas être utilisé. Tu as de la chance de ne pas être un spammeur (à moins
que tu ne le saches pas ;) Les variables HTTP POST sont disponible dans
$_POST. Je t'invite à relire le manuel PHP à ce propos.
Mais surtout, je t'encourage vivement à faire une recherche à propos
du détournement de formulaires.
du fichier PHP.ini ? Si oui, quel paramètre à modifier?
Il y a plein de raisons de sécurité qui font que ton script ne doit pas être utilisé. Tu as de la chance de ne pas être un spammeur (à moins que tu ne le saches pas ;) Les variables HTTP POST sont disponible dans $_POST. Je t'invite à relire le manuel PHP à ce propos.
Mais surtout, je t'encourage vivement à faire une recherche à propos du détournement de formulaires.
> 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?
Tes variables sont dans $_POST, tu dois donc utiliser $_POST['nom'], $_POST['email'] et $_POST['message'].
Sinon, tu peux jouer sur register_globals, mais cette fonctionnalité est obsolète et dangereuse (supprimée dans PHP6)
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Comme dit dans un autre groupe où tu as posé la même question:
> 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?
Tes variables sont dans $_POST, tu dois donc utiliser $_POST['nom'],
$_POST['email'] et $_POST['message'].
Sinon, tu peux jouer sur register_globals, mais cette fonctionnalité est
obsolète et dangereuse (supprimée dans PHP6)
--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces webmasters : http://www.c-p-f.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
> 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?
Tes variables sont dans $_POST, tu dois donc utiliser $_POST['nom'], $_POST['email'] et $_POST['message'].
Sinon, tu peux jouer sur register_globals, mais cette fonctionnalité est obsolète et dangereuse (supprimée dans PHP6)
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Freddy DISSAUX
Le 22 Sep 2008 09:05:53 GMT, CrazyCat écrivait:
Comme dit dans un autre groupe où tu as posé la même question:
> 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?
Tes variables sont dans $_POST, tu dois donc utiliser $_POST['nom'], $_POST['email'] et $_POST['message'].
Sinon, tu peux jouer sur register_globals, mais cette fonctionnalité est obsolète et dangereuse (supprimée dans PHP6)
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
> 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?
Tes variables sont dans $_POST, tu dois donc utiliser $_POST['nom'],
$_POST['email'] et $_POST['message'].
Sinon, tu peux jouer sur register_globals, mais cette fonctionnalité est
obsolète et dangereuse (supprimée dans PHP6)
Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.
> 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?
Tes variables sont dans $_POST, tu dois donc utiliser $_POST['nom'], $_POST['email'] et $_POST['message'].
Sinon, tu peux jouer sur register_globals, mais cette fonctionnalité est obsolète et dangereuse (supprimée dans PHP6)
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
-- freddy <point> dsx <arobase> free <point> fr
CrazyCat
Freddy DISSAUX wrote:
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
Pour ma part, je considère que c'est une énorme faille que de passer par $_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un formulaire utilisateur.
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Freddy DISSAUX wrote:
Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.
Pour ma part, je considère que c'est une énorme faille que de passer par
$_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un
formulaire utilisateur.
--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces webmasters : http://www.c-p-f.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
Pour ma part, je considère que c'est une énorme faille que de passer par $_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un formulaire utilisateur.
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Pascal PONCET
Freddy DISSAUX a écrit :
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST. ... Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Bonjour, Je pense que l'utilisation de $_REQUEST n'est pas cohérente avec celle de l'extension "filter", ou toute autre technique de filtrage et de validation. En effet, si l'on tient à sécuriser les données issues des clients HTTP, ce qui est hautement conseillé, on considérera également qu'il convient de tester leur méthode d'envoi, par GET ou par POST. Voir à ce sujet les recommandations de l'OWASP (www.owasp.org). Cordialement, Pascal
Freddy DISSAUX a écrit :
Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.
...
Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Bonjour,
Je pense que l'utilisation de $_REQUEST n'est pas cohérente avec celle
de l'extension "filter", ou toute autre technique de filtrage et de
validation.
En effet, si l'on tient à sécuriser les données issues des clients HTTP,
ce qui est hautement conseillé, on considérera également qu'il convient
de tester leur méthode d'envoi, par GET ou par POST.
Voir à ce sujet les recommandations de l'OWASP (www.owasp.org).
Cordialement,
Pascal
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST. ... Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Bonjour, Je pense que l'utilisation de $_REQUEST n'est pas cohérente avec celle de l'extension "filter", ou toute autre technique de filtrage et de validation. En effet, si l'on tient à sécuriser les données issues des clients HTTP, ce qui est hautement conseillé, on considérera également qu'il convient de tester leur méthode d'envoi, par GET ou par POST. Voir à ce sujet les recommandations de l'OWASP (www.owasp.org). Cordialement, Pascal
Mickaël Wolff
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.
Le 22/09/2008 16:05, Mickaël Wolff répondait à Freddy DISSAUX :
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.
Tiens, un marronnier...
Bon. Qu'il y ait une différence sémantique entre HTTP GET et HTTP POST, c'est une chose. Mais en ce qui concerne les implications en terme de sécurité, sachant qu'un attaquant peut envoyer aussi facilement un POST qu'un GET, je trouve que c'est presque mieux d'utiliser $_REQUEST, si cela incite à vérifier d'autant mieux le *contenu* des variables plutôt que leur *provenance*.
Là je suis d'accord qu'il y a potentiellement un problème si la commande mail est sensible aux « buffer overflows » ou à l'envoi de caractères de contrôle dans le corps du message : il faudrait soigneusement vérifier chaque paramètre. Cela dit, mettre $_REQUEST['email'] dans $msg, c'est quand même beaucoup moins risqué que de le mettre dans $mailheaders comme le faisait Guytou77.
Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Certes, la seule bonne idée du message.
Oh, mais c'est génial, ça ! Ça faisait longtemps que John Gallet regrettait que ça n'existe pas en standard, mais je vois que tout finit par arriver.
Le 22/09/2008 16:05, Mickaël Wolff répondait à Freddy DISSAUX :
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.
Tiens, un marronnier...
Bon. Qu'il y ait une différence sémantique entre HTTP GET et HTTP POST,
c'est une chose. Mais en ce qui concerne les implications en terme de
sécurité, sachant qu'un attaquant peut envoyer aussi facilement un POST
qu'un GET, je trouve que c'est presque mieux d'utiliser $_REQUEST, si
cela incite à vérifier d'autant mieux le *contenu* des variables plutôt
que leur *provenance*.
Là je suis d'accord qu'il y a potentiellement un problème si la commande
mail est sensible aux « buffer overflows » ou à l'envoi de caractères de
contrôle dans le corps du message : il faudrait soigneusement vérifier
chaque paramètre. Cela dit, mettre $_REQUEST['email'] dans $msg, c'est
quand même beaucoup moins risqué que de le mettre dans $mailheaders
comme le faisait Guytou77.
Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Certes, la seule bonne idée du message.
Oh, mais c'est génial, ça ! Ça faisait longtemps que John Gallet
regrettait que ça n'existe pas en standard, mais je vois que tout finit
par arriver.
Le 22/09/2008 16:05, Mickaël Wolff répondait à Freddy DISSAUX :
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.
Tiens, un marronnier...
Bon. Qu'il y ait une différence sémantique entre HTTP GET et HTTP POST, c'est une chose. Mais en ce qui concerne les implications en terme de sécurité, sachant qu'un attaquant peut envoyer aussi facilement un POST qu'un GET, je trouve que c'est presque mieux d'utiliser $_REQUEST, si cela incite à vérifier d'autant mieux le *contenu* des variables plutôt que leur *provenance*.
Là je suis d'accord qu'il y a potentiellement un problème si la commande mail est sensible aux « buffer overflows » ou à l'envoi de caractères de contrôle dans le corps du message : il faudrait soigneusement vérifier chaque paramètre. Cela dit, mettre $_REQUEST['email'] dans $msg, c'est quand même beaucoup moins risqué que de le mettre dans $mailheaders comme le faisait Guytou77.
Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Certes, la seule bonne idée du message.
Oh, mais c'est génial, ça ! Ça faisait longtemps que John Gallet regrettait que ça n'existe pas en standard, mais je vois que tout finit par arriver.
Patrick Mevzek
Le Mon, 22 Sep 2008 14:05:45 +0000, CrazyCat a écrit:
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
Pour ma part, je considère que c'est une énorme faille que de passer par $_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un formulaire utilisateur.
Si la sécurité d'une application est uniquement basée sur le fait que c'est un GET plutôt qu'un POST ou le contraire, alors cette application n'a aucune réelle mesure de sécurité.
Tous les gens qui croient corriger un problème de sécurité en changeant un GET par un POST ne comprennent en général pas grand chose au réel problème de sécurité sous-jacent.
De nombreux autres frameworks ne font pas de différence entre GET et POST (à juste raison). Ce qui me gêne davantage c'est la présence de $_COOKIE dans $_REQUEST, et c'est marrant personne ne le mentionne :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 22 Sep 2008 14:05:45 +0000, CrazyCat a écrit:
Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.
Pour ma part, je considère que c'est une énorme faille que de passer par
$_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un
formulaire utilisateur.
Si la sécurité d'une application est uniquement basée sur le fait que
c'est un GET plutôt qu'un POST ou le contraire, alors cette application
n'a aucune réelle mesure de sécurité.
Tous les gens qui croient corriger un problème de sécurité en changeant un
GET par un POST ne comprennent en général pas grand chose au réel problème
de sécurité sous-jacent.
De nombreux autres frameworks ne font pas de différence entre GET et POST
(à juste raison). Ce qui me gêne davantage c'est la présence de $_COOKIE
dans $_REQUEST, et c'est marrant personne ne le mentionne :-)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 22 Sep 2008 14:05:45 +0000, CrazyCat a écrit:
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST.
Pour ma part, je considère que c'est une énorme faille que de passer par $_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un formulaire utilisateur.
Si la sécurité d'une application est uniquement basée sur le fait que c'est un GET plutôt qu'un POST ou le contraire, alors cette application n'a aucune réelle mesure de sécurité.
Tous les gens qui croient corriger un problème de sécurité en changeant un GET par un POST ne comprennent en général pas grand chose au réel problème de sécurité sous-jacent.
De nombreux autres frameworks ne font pas de différence entre GET et POST (à juste raison). Ce qui me gêne davantage c'est la présence de $_COOKIE dans $_REQUEST, et c'est marrant personne ne le mentionne :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Patrick Mevzek
Le Mon, 22 Sep 2008 14:05:45 +0000, Mickaël Wolff 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,
S'il y a certes une différence sémantique, elle n'a pas à influer sur la façon de récupérer les paramètres envoyés par l'utilisateur, et l'application peut tout à fait savoir par différents moyens si elle est dans le cas d'un GET ou d'un POST.
ni les implications en terme de sécurité que cela implique.
Une application dont la sécurité ne dépend que de l'usage d'une méthode HTTP plutôt que d'une autre est une application sans réelle sécurité.
Absolument pas, puisque l'espace de nommage est différent : $toto vs $_REQUEST['toto'] Aucun risque d'utiliser $_REQUEST['toto'] par inadvertance dans un bout du code comme variable « locale » (non dépendante de l'extérieure.
La fausse bonne idée du register_global était de mettre dans le même espace de noms deux jeux de variables qui doivent rester séparé, car sinon il y a changement de contexte et comme je dis à mes étudiants, changement de contexte implique risque de sécurité (pas nécessairement faille de sécurité mais ca doit faire sonner une alarme et obliger à faire attention)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 22 Sep 2008 14:05:45 +0000, Mickaël Wolff 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,
S'il y a certes une différence sémantique, elle n'a pas à influer sur la
façon de récupérer les paramètres envoyés par l'utilisateur, et
l'application peut tout à fait savoir par différents moyens si elle est
dans le cas d'un GET ou d'un POST.
ni les implications en terme de sécurité que cela implique.
Une application dont la sécurité ne dépend que de l'usage d'une méthode
HTTP plutôt que d'une autre est une application sans réelle sécurité.
Absolument pas, puisque l'espace de nommage est différent : $toto vs
$_REQUEST['toto']
Aucun risque d'utiliser $_REQUEST['toto'] par inadvertance dans un bout du
code comme variable « locale » (non dépendante de l'extérieure.
La fausse bonne idée du register_global était de mettre dans le même
espace de noms deux jeux de variables qui doivent rester séparé, car sinon
il y a changement de contexte et comme je dis à mes étudiants, changement
de contexte implique risque de sécurité (pas nécessairement faille de
sécurité mais ca doit faire sonner une alarme et obliger à faire attention)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 22 Sep 2008 14:05:45 +0000, Mickaël Wolff 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,
S'il y a certes une différence sémantique, elle n'a pas à influer sur la façon de récupérer les paramètres envoyés par l'utilisateur, et l'application peut tout à fait savoir par différents moyens si elle est dans le cas d'un GET ou d'un POST.
ni les implications en terme de sécurité que cela implique.
Une application dont la sécurité ne dépend que de l'usage d'une méthode HTTP plutôt que d'une autre est une application sans réelle sécurité.
Absolument pas, puisque l'espace de nommage est différent : $toto vs $_REQUEST['toto'] Aucun risque d'utiliser $_REQUEST['toto'] par inadvertance dans un bout du code comme variable « locale » (non dépendante de l'extérieure.
La fausse bonne idée du register_global était de mettre dans le même espace de noms deux jeux de variables qui doivent rester séparé, car sinon il y a changement de contexte et comme je dis à mes étudiants, changement de contexte implique risque de sécurité (pas nécessairement faille de sécurité mais ca doit faire sonner une alarme et obliger à faire attention)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Patrick Mevzek
Le Mon, 22 Sep 2008 14:05:45 +0000, Pascal PONCET a écrit:
Freddy DISSAUX a écrit :
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST. ... Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Je pense que l'utilisation de $_REQUEST n'est pas cohérente avec celle de l'extension "filter", ou toute autre technique de filtrage et de validation.
Deux choses complétement orthogonales.
En effet, si l'on tient à sécuriser les données issues des clients HTTP, ce qui est hautement conseillé, on considérera également qu'il convient de tester leur méthode d'envoi, par GET ou par POST.
Il suffit donc de tester $_SERVER['REQUEST_METHOD'] si c'est réellement nécessaire. Aucun rapport avec l'usage de $_REQUEST.
Mais autant espérer que la sécurité de l'application ne dépende pas de cela, sans quoi...
Voir à ce sujet les recommandations de l'OWASP (www.owasp.org).
Quelles sont celles qui interdisent l'usage de $_REQUEST ?
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 22 Sep 2008 14:05:45 +0000, Pascal PONCET a écrit:
Freddy DISSAUX a écrit :
Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.
...
Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Je pense que l'utilisation de $_REQUEST n'est pas cohérente avec celle
de l'extension "filter", ou toute autre technique de filtrage et de
validation.
Deux choses complétement orthogonales.
En effet, si l'on tient à sécuriser les données issues des clients HTTP,
ce qui est hautement conseillé, on considérera également qu'il convient
de tester leur méthode d'envoi, par GET ou par POST.
Il suffit donc de tester $_SERVER['REQUEST_METHOD']
si c'est réellement nécessaire.
Aucun rapport avec l'usage de $_REQUEST.
Mais autant espérer que la sécurité de l'application ne dépende pas de
cela, sans quoi...
Voir à ce sujet les recommandations de l'OWASP (www.owasp.org).
Quelles sont celles qui interdisent l'usage de $_REQUEST ?
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 22 Sep 2008 14:05:45 +0000, Pascal PONCET a écrit:
Freddy DISSAUX a écrit :
Personnellement, je recommande chaudement l'utilisation de $_REQUEST pour éviter les mélimélo $_GET/$_POST. ... Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter
Je pense que l'utilisation de $_REQUEST n'est pas cohérente avec celle de l'extension "filter", ou toute autre technique de filtrage et de validation.
Deux choses complétement orthogonales.
En effet, si l'on tient à sécuriser les données issues des clients HTTP, ce qui est hautement conseillé, on considérera également qu'il convient de tester leur méthode d'envoi, par GET ou par POST.
Il suffit donc de tester $_SERVER['REQUEST_METHOD'] si c'est réellement nécessaire. Aucun rapport avec l'usage de $_REQUEST.
Mais autant espérer que la sécurité de l'application ne dépende pas de cela, sans quoi...
Voir à ce sujet les recommandations de l'OWASP (www.owasp.org).
Quelles sont celles qui interdisent l'usage de $_REQUEST ?
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>