Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage PHP Aucune recuperation des champs du formulaire

Aucune recuperation des champs du formulaire

24 réponses
Avatar
Guytou77
Bonjour à Tous,

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:

Nom:
E-Mail:
Message:

Aucun champ de mon formulaire n'est recupérée.

Voici mon formulaire (formulaire.html)

<FORM method="POST" action="envoi.php">
<P>Votre nom:<br>
<INPUT type="text" name="nom" size=30>
</p>
<P>Votre adresse E-Mail:<br>
<INPUT type="text" name="email" size=30>
</p>
<P>Message:<br>
<textarea name="message" cols=30 rows=5></textarea>
</p><INPUT type="submit" value="Envoyer">
</FORM>

Voici mon script de recupération et envoie de données du formulaire
(envoi.php):

<?php
$msg = "Nom:\t$nom\n";
$msg .= "E-Mail:\t$email\n";
$msg .= "Message:\t$message\n\n";

$recipient = "XXXXX@yahoo.fr";
$subject = "Formulaire";
$mailheaders = "From: Mon test de formulaire<> \n";
$mailheaders .= "Reply-To: $email\n\n";
mail($recipient, $subject, $msg, $mailheaders);

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?

Cordialement,

Guytou77
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Mickaël Wolff
Guytou77 a écrit :

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.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Avatar
CrazyCat
Comme dit dans un autre groupe où tu as posé la même question:

Guytou77 wrote:
> $msg = "Nom:t$nomn";
> $msg .= "E-Mail:t$emailn";
> $msg .= "Message:t$messagenn";

> 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
Avatar
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:

Guytou77 wrote:
> $msg = "Nom:t$nomn";
> $msg .= "E-Mail:t$emailn";
> $msg .= "Message:t$messagenn";

> 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.

Avec un heredoc du plus bel effet:

$msg = <<<EOT;
Nom: {$_REQUEST['nom']}
E-Mail: {$_REQUEST['email']}
Message: {$_REQUEST['message']}


EOT;

Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter

--
freddy <point> dsx <arobase> free <point> fr
Avatar
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
Avatar
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
Avatar
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.


Avec un heredoc du plus bel effet:

$msg = <<<EOT;
Nom: {$_REQUEST['nom']}
E-Mail: {$_REQUEST['email']}
Message: {$_REQUEST['message']}



EOT;



Comme au bon vieux temps du global_register.


Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter



Certes, la seule bonne idée du message.


--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Avatar
Olivier Miakinen
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*.

Avec un heredoc du plus bel effet:

$msg = <<<EOT;
Nom: {$_REQUEST['nom']}
E-Mail: {$_REQUEST['email']}
Message: {$_REQUEST['message']}



EOT;



Comme au bon vieux temps du global_register.



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.
Avatar
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/>
Avatar
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é.

Avec un heredoc du plus bel effet:

$msg = <<<EOT;
Nom: {$_REQUEST['nom']}
E-Mail: {$_REQUEST['email']}
Message: {$_REQUEST['message']}



EOT;



Comme au bon vieux temps du global_register.



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/>
Avatar
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/>
1 2 3