Bonsoir,
Un formulaire contient des menus déroulants . Lors des retours, je
reçois par défaut la première option affichée par la boite "menu" si pas
d'autre choix effectué par l'utilisateur.
Si "menu" propose "option1 / option 2 / option 3"
le retour me donne " menu : option 1" (ou 2 ou 3 si un choix est fait)
mais normalement jamais "menu :" tout seul même si le visiteur
n'effectue aucun choix et envoie le submit dès l'ouverture de la page
(j'ai testé ).
Mais voilà que je reçois de tps en tps des retours vides du type "
menu: "
Comment se fait-ce ??? :-)
Le formulaire est en html, traité avec php dans une autre page.
Il est en bas de cette page : http://autourdalos.fr/html/auteur.htm
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
Olivier Miakinen
Le 07/04/2009 16:42, alainL a écrit :
Un formulaire contient des menus déroulants . Lors des retours, je reçois par défaut la première option affichée par la boite "menu" si pas d'autre choix effectué par l'utilisateur.
[...]
Mais voilà que je reçois de tps en tps des retours vides du type " menu: "
Comment se fait-ce ??? :-)
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des données qui ne correspondent pas à ce que tu est prêt à accepter, tu renvoies un message d'erreur (poli s'il y a une chance que cela vienne d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement malpoli si tu es sûr et certain que c'est un spammeur).
Le 07/04/2009 16:42, alainL a écrit :
Un formulaire contient des menus déroulants . Lors des retours, je
reçois par défaut la première option affichée par la boite "menu" si pas
d'autre choix effectué par l'utilisateur.
[...]
Mais voilà que je reçois de tps en tps des retours vides du type "
menu: "
Comment se fait-ce ??? :-)
Première hypothèse : un visiteur utilise un navigateur qui ne se
comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en
lui envoyant des requêtes autres que celles que génèrerait un navigateur
normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des
données qui ne correspondent pas à ce que tu est prêt à accepter, tu
renvoies un message d'erreur (poli s'il y a une chance que cela vienne
d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement
malpoli si tu es sûr et certain que c'est un spammeur).
Un formulaire contient des menus déroulants . Lors des retours, je reçois par défaut la première option affichée par la boite "menu" si pas d'autre choix effectué par l'utilisateur.
[...]
Mais voilà que je reçois de tps en tps des retours vides du type " menu: "
Comment se fait-ce ??? :-)
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des données qui ne correspondent pas à ce que tu est prêt à accepter, tu renvoies un message d'erreur (poli s'il y a une chance que cela vienne d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement malpoli si tu es sûr et certain que c'est un spammeur).
alainL
Olivier Miakinen a écrit :
Le 07/04/2009 16:42, alainL a écrit :
Un formulaire contient des menus déroulants . Lors des retours, je reçois par défaut la première option affichée par la boite "menu" si pas d'autre choix effectué par l'utilisateur.
[...]
Mais voilà que je reçois de tps en tps des retours vides du type " menu: "
Comment se fait-ce ??? :-)
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des données qui ne correspondent pas à ce que tu est prêt à accepter, tu renvoies un message d'erreur (poli s'il y a une chance que cela vienne d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement malpoli si tu es sûr et certain que c'est un spammeur).
Il me semble qu'il utilise Mozilla (code source du message) Les codes de messages "normaux" et des "bizarres" sont d'ailleurs quasiment identiques. Mais son adresse n'apparait nulle part ! Tu parles d'un test lors du traitement php des données avant l'envoi alors ?
-- Alain L
Olivier Miakinen a écrit :
Le 07/04/2009 16:42, alainL a écrit :
Un formulaire contient des menus déroulants . Lors des retours, je
reçois par défaut la première option affichée par la boite "menu" si pas
d'autre choix effectué par l'utilisateur.
[...]
Mais voilà que je reçois de tps en tps des retours vides du type "
menu: "
Comment se fait-ce ??? :-)
Première hypothèse : un visiteur utilise un navigateur qui ne se
comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en
lui envoyant des requêtes autres que celles que génèrerait un navigateur
normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des
données qui ne correspondent pas à ce que tu est prêt à accepter, tu
renvoies un message d'erreur (poli s'il y a une chance que cela vienne
d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement
malpoli si tu es sûr et certain que c'est un spammeur).
Il me semble qu'il utilise Mozilla (code source du message)
Les codes de messages "normaux" et des "bizarres" sont d'ailleurs
quasiment identiques.
Mais son adresse n'apparait nulle part !
Tu parles d'un test lors du traitement php des données avant l'envoi
alors ?
Un formulaire contient des menus déroulants . Lors des retours, je reçois par défaut la première option affichée par la boite "menu" si pas d'autre choix effectué par l'utilisateur.
[...]
Mais voilà que je reçois de tps en tps des retours vides du type " menu: "
Comment se fait-ce ??? :-)
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des données qui ne correspondent pas à ce que tu est prêt à accepter, tu renvoies un message d'erreur (poli s'il y a une chance que cela vienne d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement malpoli si tu es sûr et certain que c'est un spammeur).
Il me semble qu'il utilise Mozilla (code source du message) Les codes de messages "normaux" et des "bizarres" sont d'ailleurs quasiment identiques. Mais son adresse n'apparait nulle part ! Tu parles d'un test lors du traitement php des données avant l'envoi alors ?
-- Alain L
Olivier Miakinen
Le 07/04/2009 18:57, alainL a écrit :
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des données qui ne correspondent pas à ce que tu est prêt à accepter, tu renvoies un message d'erreur (poli s'il y a une chance que cela vienne d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement malpoli si tu es sûr et certain que c'est un spammeur).
Il me semble qu'il utilise Mozilla (code source du message)
Ben ça, à moins de pouvoir le contacter et qu'il te réponde (ce que ne ferait bien sûr pas un spammeur), tu ne peux pas le savoir. D'ailleurs qu'appelles-tu le « code source du message », s'agissant d'une requête HTTP ?
Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut envoyer tous les paramètres que l'on veut, y compris une chaîne contenant « Mozilla » dans HTTP_USER_AGENT.
Les codes de messages "normaux" et des "bizarres" sont d'ailleurs quasiment identiques. Mais son adresse n'apparait nulle part !
Message ?... Adresse ???
Sois un peu plus clair dans les paramètres qui viennent de l'extérieur et dont tu parles ici, car là je ne comprends que dalle.
Tu parles d'un test lors du traitement php des données avant l'envoi alors ?
Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la réponse est évidemment non. Le moment où il faut tester les paramètres, c'est à la réception de la requête qui te vient du visiteur lorsqu'il clique sur le bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le cas d'un spammeur qui essaye de détourner ton formulaire).
Le 07/04/2009 18:57, alainL a écrit :
Première hypothèse : un visiteur utilise un navigateur qui ne se
comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en
lui envoyant des requêtes autres que celles que génèrerait un navigateur
normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des
données qui ne correspondent pas à ce que tu est prêt à accepter, tu
renvoies un message d'erreur (poli s'il y a une chance que cela vienne
d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement
malpoli si tu es sûr et certain que c'est un spammeur).
Il me semble qu'il utilise Mozilla (code source du message)
Ben ça, à moins de pouvoir le contacter et qu'il te réponde (ce que ne
ferait bien sûr pas un spammeur), tu ne peux pas le savoir. D'ailleurs
qu'appelles-tu le « code source du message », s'agissant d'une requête
HTTP ?
Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut
envoyer tous les paramètres que l'on veut, y compris une chaîne
contenant « Mozilla » dans HTTP_USER_AGENT.
Les codes de messages "normaux" et des "bizarres" sont d'ailleurs
quasiment identiques.
Mais son adresse n'apparait nulle part !
Message ?... Adresse ???
Sois un peu plus clair dans les paramètres qui viennent de l'extérieur
et dont tu parles ici, car là je ne comprends que dalle.
Tu parles d'un test lors du traitement php des données avant l'envoi
alors ?
Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la réponse est
évidemment non. Le moment où il faut tester les paramètres, c'est à la
réception de la requête qui te vient du visiteur lorsqu'il clique sur le
bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le
cas d'un spammeur qui essaye de détourner ton formulaire).
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des données qui ne correspondent pas à ce que tu est prêt à accepter, tu renvoies un message d'erreur (poli s'il y a une chance que cela vienne d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement malpoli si tu es sûr et certain que c'est un spammeur).
Il me semble qu'il utilise Mozilla (code source du message)
Ben ça, à moins de pouvoir le contacter et qu'il te réponde (ce que ne ferait bien sûr pas un spammeur), tu ne peux pas le savoir. D'ailleurs qu'appelles-tu le « code source du message », s'agissant d'une requête HTTP ?
Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut envoyer tous les paramètres que l'on veut, y compris une chaîne contenant « Mozilla » dans HTTP_USER_AGENT.
Les codes de messages "normaux" et des "bizarres" sont d'ailleurs quasiment identiques. Mais son adresse n'apparait nulle part !
Message ?... Adresse ???
Sois un peu plus clair dans les paramètres qui viennent de l'extérieur et dont tu parles ici, car là je ne comprends que dalle.
Tu parles d'un test lors du traitement php des données avant l'envoi alors ?
Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la réponse est évidemment non. Le moment où il faut tester les paramètres, c'est à la réception de la requête qui te vient du visiteur lorsqu'il clique sur le bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le cas d'un spammeur qui essaye de détourner ton formulaire).
alainL
Olivier Miakinen a écrit :
Le 07/04/2009 18:57, alainL a écrit :
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
...............
Il me semble qu'il utilise Mozilla (code source du message)
.................
qu'appelles-tu le « code source du message », s'agissant d'une requête HTTP ?
Ce que Thunderbird appelle ainsi : _______________________________________________________________ From - Sun Apr 05 10:42:27 2009 X-Account-Key: account5 X-UIDL: 727.1238908572 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys:
Received: from .............. (............. [xx.xxx.xx.xxx]) by relay-9m.club-internet.fr (Postfix) with ESMTP id xxxxxxxxx for ; Sun, 5 Apr 2009 07:16:11 +0200 (CEST) Received: from ............. (............... [xxx.x.x.x]) by .............. (x.xx.x/x.x.x) with ESMTP id xxxxxxxxxxxxxxxxx for ; Sun, 5 Apr 2009 06:16:11 +0100 Received: (from ) by ............. (x.xx.x/x.xx.x/Submit) id xxxxxxxxx; Sun, 5 Apr 2009 06:16:11 +0100 Date: Sun, 5 Apr 2009 06:16:11 +0100 Message-Id: To: Subject: depuis le site Autour d'Alos From: Un visiteur <> Reply-To: Status: X-Mmail: Recent X-M-Uid: xxx.xxxxxx X-Antivirus: avast! (VPS 090404-0, 04/04/2009), Inbound message X-Antivirus-Status: Clean
Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut envoyer tous les paramètres que l'on veut, y compris une chaîne contenant « Mozilla » dans HTTP_USER_AGENT.
OK
Tu parles d'un test lors du traitement php des données avant l'envoi alors ?
Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la réponse est évidemment non. Le moment où il faut tester les paramètres, c'est à la réception de la requête qui te vient du visiteur lorsqu'il clique sur le bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le cas d'un spammeur qui essaye de détourner ton formulaire).
Oui, entre le "submit" du formulaire et le "mail($to,$message);" du traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ? -- Alain L
Olivier Miakinen a écrit :
Le 07/04/2009 18:57, alainL a écrit :
Première hypothèse : un visiteur utilise un navigateur qui ne se
comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en
lui envoyant des requêtes autres que celles que génèrerait un navigateur
normal.
...............
Il me semble qu'il utilise Mozilla (code source du message)
.................
qu'appelles-tu le « code source du message », s'agissant d'une requête
HTTP ?
Ce que Thunderbird appelle ainsi :
_______________________________________________________________
From - Sun Apr 05 10:42:27 2009
X-Account-Key: account5
X-UIDL: 727.1238908572
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Received: from .............. (............. [xx.xxx.xx.xxx])
by relay-9m.club-internet.fr (Postfix) with ESMTP id xxxxxxxxx
for <mon.site@club-internet.fr>; Sun, 5 Apr 2009 07:16:11 +0200 (CEST)
Received: from ............. (............... [xxx.x.x.x])
by .............. (x.xx.x/x.x.x) with ESMTP id xxxxxxxxxxxxxxxxx
for <monsite@club-internet.fr>; Sun, 5 Apr 2009 06:16:11 +0100
Received: (from autourdalos.fr@localhost)
by ............. (x.xx.x/x.xx.x/Submit) id xxxxxxxxx;
Sun, 5 Apr 2009 06:16:11 +0100
Date: Sun, 5 Apr 2009 06:16:11 +0100
Message-Id: <xxxxx.xxxxx@xxxxxxxxxxxxx.uk>
To: monsite@club-internet.fr
Subject: depuis le site Autour d'Alos
From: Un visiteur <>
Reply-To:
Status:
X-Mmail: Recent
X-M-Uid: xxx.xxxxxx
X-Antivirus: avast! (VPS 090404-0, 04/04/2009), Inbound message
X-Antivirus-Status: Clean
Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut
envoyer tous les paramètres que l'on veut, y compris une chaîne
contenant « Mozilla » dans HTTP_USER_AGENT.
OK
Tu parles d'un test lors du traitement php des données avant l'envoi
alors ?
Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la réponse est
évidemment non. Le moment où il faut tester les paramètres, c'est à la
réception de la requête qui te vient du visiteur lorsqu'il clique sur le
bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le
cas d'un spammeur qui essaye de détourner ton formulaire).
Oui, entre le "submit" du formulaire et le "mail($to,$message);" du
traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous
n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ?
--
Alain L
Première hypothèse : un visiteur utilise un navigateur qui ne se comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en lui envoyant des requêtes autres que celles que génèrerait un navigateur normal.
...............
Il me semble qu'il utilise Mozilla (code source du message)
.................
qu'appelles-tu le « code source du message », s'agissant d'une requête HTTP ?
Ce que Thunderbird appelle ainsi : _______________________________________________________________ From - Sun Apr 05 10:42:27 2009 X-Account-Key: account5 X-UIDL: 727.1238908572 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys:
Received: from .............. (............. [xx.xxx.xx.xxx]) by relay-9m.club-internet.fr (Postfix) with ESMTP id xxxxxxxxx for ; Sun, 5 Apr 2009 07:16:11 +0200 (CEST) Received: from ............. (............... [xxx.x.x.x]) by .............. (x.xx.x/x.x.x) with ESMTP id xxxxxxxxxxxxxxxxx for ; Sun, 5 Apr 2009 06:16:11 +0100 Received: (from ) by ............. (x.xx.x/x.xx.x/Submit) id xxxxxxxxx; Sun, 5 Apr 2009 06:16:11 +0100 Date: Sun, 5 Apr 2009 06:16:11 +0100 Message-Id: To: Subject: depuis le site Autour d'Alos From: Un visiteur <> Reply-To: Status: X-Mmail: Recent X-M-Uid: xxx.xxxxxx X-Antivirus: avast! (VPS 090404-0, 04/04/2009), Inbound message X-Antivirus-Status: Clean
Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut envoyer tous les paramètres que l'on veut, y compris une chaîne contenant « Mozilla » dans HTTP_USER_AGENT.
OK
Tu parles d'un test lors du traitement php des données avant l'envoi alors ?
Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la réponse est évidemment non. Le moment où il faut tester les paramètres, c'est à la réception de la requête qui te vient du visiteur lorsqu'il clique sur le bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le cas d'un spammeur qui essaye de détourner ton formulaire).
Oui, entre le "submit" du formulaire et le "mail($to,$message);" du traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ? -- Alain L
Olivier Miakinen
Le 08/04/2009 14:59, alainL a écrit :
Il me semble qu'il utilise Mozilla (code source du message)
qu'appelles-tu le « code source du message », s'agissant d'une requête HTTP ?
Ce que Thunderbird appelle ainsi :
Hahaha ! C'est un troll ? Tu ne nous montre pas une requête HTTP, mais le code source d'un courriel ! Qui plus est...
_______________________________________________________________ From - Sun Apr 05 10:42:27 2009 X-Account-Key: account5 X-UIDL: 727.1238908572 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys:
... si c'est ça qui te fait croire que le visiteur utilise Mozilla, j'ai bien l'impression que tu te trompes doublement. Je crois moi que c'est ton propre serveur web qui génère le message, et que c'est ton propre client Thunderbird qui ajoute les entêtes X-Mozilla-* ! :-D
[...] entre le "submit" du formulaire et le "mail($to,$message);" du traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ?
Le bout de code, c'est au tout début du programme PHP que tu dois le mettre, et ce bout de code doit contrôler *toutes* les variables qui viennent de l'extérieur avant d'envisager une seule seconde de faire appel à une fonction aussi dangereuse que mail().
Je crois d'ailleurs que tu fréquentes le forum fr.comp.lang.php depuis suffisamment longtemps pour avoir vu tous les conseils (toujours les mêmes) que je donne à tous ceux qui viennent avec un script PHP faisant appel à la fonction mail(). Alors s'il te plaît commence par relire une petite demi-douzaine de ces messages, puis s'il te reste des questions après cela viens soumettre ton script sur ledit forum.
Le 08/04/2009 14:59, alainL a écrit :
Il me semble qu'il utilise Mozilla (code source du message)
qu'appelles-tu le « code source du message », s'agissant d'une requête
HTTP ?
Ce que Thunderbird appelle ainsi :
Hahaha ! C'est un troll ? Tu ne nous montre pas une requête HTTP, mais
le code source d'un courriel ! Qui plus est...
_______________________________________________________________
From - Sun Apr 05 10:42:27 2009
X-Account-Key: account5
X-UIDL: 727.1238908572
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
... si c'est ça qui te fait croire que le visiteur utilise Mozilla, j'ai
bien l'impression que tu te trompes doublement. Je crois moi que c'est
ton propre serveur web qui génère le message, et que c'est ton propre
client Thunderbird qui ajoute les entêtes X-Mozilla-* ! :-D
[...] entre le "submit" du formulaire et le "mail($to,$message);" du
traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous
n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ?
Le bout de code, c'est au tout début du programme PHP que tu dois le
mettre, et ce bout de code doit contrôler *toutes* les variables qui
viennent de l'extérieur avant d'envisager une seule seconde de faire
appel à une fonction aussi dangereuse que mail().
Je crois d'ailleurs que tu fréquentes le forum fr.comp.lang.php depuis
suffisamment longtemps pour avoir vu tous les conseils (toujours les
mêmes) que je donne à tous ceux qui viennent avec un script PHP faisant
appel à la fonction mail(). Alors s'il te plaît commence par relire une
petite demi-douzaine de ces messages, puis s'il te reste des questions
après cela viens soumettre ton script sur ledit forum.
Il me semble qu'il utilise Mozilla (code source du message)
qu'appelles-tu le « code source du message », s'agissant d'une requête HTTP ?
Ce que Thunderbird appelle ainsi :
Hahaha ! C'est un troll ? Tu ne nous montre pas une requête HTTP, mais le code source d'un courriel ! Qui plus est...
_______________________________________________________________ From - Sun Apr 05 10:42:27 2009 X-Account-Key: account5 X-UIDL: 727.1238908572 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys:
... si c'est ça qui te fait croire que le visiteur utilise Mozilla, j'ai bien l'impression que tu te trompes doublement. Je crois moi que c'est ton propre serveur web qui génère le message, et que c'est ton propre client Thunderbird qui ajoute les entêtes X-Mozilla-* ! :-D
[...] entre le "submit" du formulaire et le "mail($to,$message);" du traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ?
Le bout de code, c'est au tout début du programme PHP que tu dois le mettre, et ce bout de code doit contrôler *toutes* les variables qui viennent de l'extérieur avant d'envisager une seule seconde de faire appel à une fonction aussi dangereuse que mail().
Je crois d'ailleurs que tu fréquentes le forum fr.comp.lang.php depuis suffisamment longtemps pour avoir vu tous les conseils (toujours les mêmes) que je donne à tous ceux qui viennent avec un script PHP faisant appel à la fonction mail(). Alors s'il te plaît commence par relire une petite demi-douzaine de ces messages, puis s'il te reste des questions après cela viens soumettre ton script sur ledit forum.
Michael DENIS
Olivier Miakinen a écrit :
Le bout de code, c'est au tout début du programme PHP que tu dois le mettre, et ce bout de code doit contrôler *toutes* les variables qui viennent de l'extérieur avant d'envisager une seule seconde de faire appel à une fonction aussi dangereuse que mail().
Je crois que pour bien se protéger, il faut commencer par bien comprendre comment un spammeur peut utiliser un code mal sécurisé. Je ne peux qu'encourager la lecture d'articles tels que celui-ci :
qui permet de mieux comprendre le problème de la fonction mail en particulier, mais aussi finalement du risque lié à des passages de variables de façon générale.
-- Michaël DENIS
Olivier Miakinen a écrit :
Le bout de code, c'est au tout début du programme PHP que tu dois le
mettre, et ce bout de code doit contrôler *toutes* les variables qui
viennent de l'extérieur avant d'envisager une seule seconde de faire
appel à une fonction aussi dangereuse que mail().
Je crois que pour bien se protéger, il faut commencer par bien
comprendre comment un spammeur peut utiliser un code mal sécurisé. Je ne
peux qu'encourager la lecture d'articles tels que celui-ci :
qui permet de mieux comprendre le problème de la fonction mail en
particulier, mais aussi finalement du risque lié à des passages de
variables de façon générale.
Le bout de code, c'est au tout début du programme PHP que tu dois le mettre, et ce bout de code doit contrôler *toutes* les variables qui viennent de l'extérieur avant d'envisager une seule seconde de faire appel à une fonction aussi dangereuse que mail().
Je crois que pour bien se protéger, il faut commencer par bien comprendre comment un spammeur peut utiliser un code mal sécurisé. Je ne peux qu'encourager la lecture d'articles tels que celui-ci :
qui permet de mieux comprendre le problème de la fonction mail en particulier, mais aussi finalement du risque lié à des passages de variables de façon générale.
