Marre des spammeurs qui à la longue m'inondent de messages indésirables
par l'intermédiaire de mes formulaires ! J'ai cherché des solutions sur
le Web sans trouver celle que je voudrais mettre en oeuvre. Il y est le
plus souvent question de "captcha" sous forme de chaînes de caractères
générées aléatoirement par un script PHP mais celles-ci sont bien
souvent illisibles.
Comme l'essentiel des spams est fait de liens, que ceux-ci sont
répétitifs dans le même message, j'aimerais trouver un script à insérer
soit dans le formulaire, soit dans le script PHP de traitement de
celui-ci. Le principe serait soit d'interdire toute écriture d'un lien
comme ceci, par exemple :
(les noms armo et Avis sont repris d'un de mes formulaires visibles à
http://armorance.free.fr/formArmo.html)
soit de créer une condition du même genre mais dont le résultat serait
de refuser l'écriture de plus d'une chaîne de caractères *identique* de
7 lettres (par exemple) dans le même "textarea",
soit de créer ce même genre de contrôle mais dans le script PHP.
Malheureusement, l'âge et la mémoire :-( font que mes faibles notions de
JS que j'ai abandonnées depuis près de 10 ans ne me permettent plus de
coder une telle condition qui me paraît pourtant simple (le plus évident
étant toujours celui qu'on voit le moins ...) et pour ce qui est du PHP,
je suis une véritable bille.
Quelqu'un peut-il m'aider à réaliser ce petit script sur lequel je butte
sans trouver la solution ?
Cordialement,
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Mais il faut bien écrire une "condition" dans le script qui permettra, ou non, de valider le formulaire.
Euh. Oui ?
En JS, cela semble aléatoire, en PHP c'est plus efficace. Si ta solution était codée dans ce dernier langage, n'hésite pas à la reproduire ici : je suis tout regard, à défaut d'être tout ouïe :-)
// Où $piege correspond à la variable envoyée en $_POST, et où le visiteur aura rempli la séquence "1234" demandée if ($piege == "1234") {
// code de validation du formulaire
}
En gros, c'est comme un captcha, sans l'image. :-)
docanski wrote:
Mais il faut bien écrire une "condition" dans le script qui permettra,
ou non, de valider le formulaire.
Euh. Oui ?
En JS, cela semble aléatoire, en PHP c'est plus efficace. Si ta solution
était codée dans ce dernier langage, n'hésite pas à la reproduire ici :
je suis tout regard, à défaut d'être tout ouïe :-)
// Où $piege correspond à la variable envoyée en $_POST, et où le
visiteur aura rempli la séquence "1234" demandée
if ($piege == "1234")
{
// code de validation du formulaire
}
En gros, c'est comme un captcha, sans l'image. :-)
Mais il faut bien écrire une "condition" dans le script qui permettra, ou non, de valider le formulaire.
Euh. Oui ?
En JS, cela semble aléatoire, en PHP c'est plus efficace. Si ta solution était codée dans ce dernier langage, n'hésite pas à la reproduire ici : je suis tout regard, à défaut d'être tout ouïe :-)
// Où $piege correspond à la variable envoyée en $_POST, et où le visiteur aura rempli la séquence "1234" demandée if ($piege == "1234") {
// code de validation du formulaire
}
En gros, c'est comme un captcha, sans l'image. :-)
none
Olivier Miakinen wrote:
if ($_POST['controle'] == "1234") { ... }
Oups. J'avions pas vu. C'est effectivement la bonne réponse. Ca a tenu des années, en piégeant les spammeurs (je loguais tout ce qui ne passait pas).
Olivier Miakinen wrote:
if ($_POST['controle'] == "1234") {
...
}
Oups. J'avions pas vu. C'est effectivement la bonne réponse. Ca a tenu
des années, en piégeant les spammeurs (je loguais tout ce qui ne passait
pas).
Oups. J'avions pas vu. C'est effectivement la bonne réponse. Ca a tenu des années, en piégeant les spammeurs (je loguais tout ce qui ne passait pas).
Olivier Masson
Laurent vilday a écrit :
J'ai du mal à comprendre le raisonnement. On est pas tout à fait dans la même logique qu'un logiciel client ou serveur qu'il *faut* mettre à jour suite à la correction de certains bugs et autres trous de sécurité. Non, là on est dans l'évolution non désirée et non indispensable d'un langage.
Pas envie de rentrer dans un troll, pas le temps. Simplement, tu as du loupé un truc : le moment où on t'apprenais que php était utilisé, à l'instar de perl, python (et ruby) pour le développement web. On te dit pas que coder en php4 c'est moins bien (quoique), on te dit que php4 ne sera plus maintenu.
Donc en quoi l'arrêt du support PHP4 rendrait la non utilisation de PHP5 stupide ? Ceux qui font du C sont-ils plus stupides que ceux qui font du C++ ? Parce que je fait l'impasse sur la langage D, ça me rendrait plus stupide que ceux qui parient sur ce langage ?
Aucun rapport.
Tu vas faire la transition de tout ce qui est en PHP4 vers du PHP5 ou tu vas les laisser en PHP4 ? Pourquoi changer puisque l'outil fonctionne bien qu'utilisant PHP4 ?
Il m'a fallu 1 heure ou 2 pour migrer un dizaine de sites. En fait, c'était uniquement du test puisque un seul site n'a pas fonctionné (par ma faute : php5 était moins permissif.)
Donc oui on (ma boite) va encore faire du PHP4 pendant de nombreux mois voir années et je ne me sens pas plus *stupide* que toi ou un autre, merci.
Tu me donneras son nom que je la déconseille à mes clients :) Tu peux utiliser Perl 4 aussi si tu veux, et chercher un module de TurboPascal pour Apache (1.3 bien sûr !)
Laurent vilday a écrit :
J'ai du mal à comprendre le raisonnement. On est pas tout à fait dans la
même logique qu'un logiciel client ou serveur qu'il *faut* mettre à jour
suite à la correction de certains bugs et autres trous de sécurité. Non,
là on est dans l'évolution non désirée et non indispensable d'un langage.
Pas envie de rentrer dans un troll, pas le temps.
Simplement, tu as du loupé un truc : le moment où on t'apprenais que php
était utilisé, à l'instar de perl, python (et ruby) pour le
développement web.
On te dit pas que coder en php4 c'est moins bien (quoique), on te dit
que php4 ne sera plus maintenu.
Donc en quoi l'arrêt du support PHP4 rendrait la non utilisation de PHP5
stupide ? Ceux qui font du C sont-ils plus stupides que ceux qui font du
C++ ? Parce que je fait l'impasse sur la langage D, ça me rendrait plus
stupide que ceux qui parient sur ce langage ?
Aucun rapport.
Tu vas faire la transition de tout ce qui est en PHP4 vers du PHP5 ou tu
vas les laisser en PHP4 ? Pourquoi changer puisque l'outil fonctionne
bien qu'utilisant PHP4 ?
Il m'a fallu 1 heure ou 2 pour migrer un dizaine de sites. En fait,
c'était uniquement du test puisque un seul site n'a pas fonctionné (par
ma faute : php5 était moins permissif.)
Donc oui on (ma boite) va encore faire du PHP4 pendant de nombreux mois
voir années et je ne me sens pas plus *stupide* que toi ou un autre, merci.
Tu me donneras son nom que je la déconseille à mes clients :)
Tu peux utiliser Perl 4 aussi si tu veux, et chercher un module de
TurboPascal pour Apache (1.3 bien sûr !)
J'ai du mal à comprendre le raisonnement. On est pas tout à fait dans la même logique qu'un logiciel client ou serveur qu'il *faut* mettre à jour suite à la correction de certains bugs et autres trous de sécurité. Non, là on est dans l'évolution non désirée et non indispensable d'un langage.
Pas envie de rentrer dans un troll, pas le temps. Simplement, tu as du loupé un truc : le moment où on t'apprenais que php était utilisé, à l'instar de perl, python (et ruby) pour le développement web. On te dit pas que coder en php4 c'est moins bien (quoique), on te dit que php4 ne sera plus maintenu.
Donc en quoi l'arrêt du support PHP4 rendrait la non utilisation de PHP5 stupide ? Ceux qui font du C sont-ils plus stupides que ceux qui font du C++ ? Parce que je fait l'impasse sur la langage D, ça me rendrait plus stupide que ceux qui parient sur ce langage ?
Aucun rapport.
Tu vas faire la transition de tout ce qui est en PHP4 vers du PHP5 ou tu vas les laisser en PHP4 ? Pourquoi changer puisque l'outil fonctionne bien qu'utilisant PHP4 ?
Il m'a fallu 1 heure ou 2 pour migrer un dizaine de sites. En fait, c'était uniquement du test puisque un seul site n'a pas fonctionné (par ma faute : php5 était moins permissif.)
Donc oui on (ma boite) va encore faire du PHP4 pendant de nombreux mois voir années et je ne me sens pas plus *stupide* que toi ou un autre, merci.
Tu me donneras son nom que je la déconseille à mes clients :) Tu peux utiliser Perl 4 aussi si tu veux, et chercher un module de TurboPascal pour Apache (1.3 bien sûr !)
Michael DENIS
Denis Beauregard a écrit :
Mais on s'en fout ! Je veux dire qu'on a 3 cas de figure :
- usage humain avec javascript -> il peut envoyer un message - usage humain sans javascript -> il ne peut pas envoyer un message (donc, si on utilise cette méthode, il faudrait remplacer le champ "texte" par un "activez le javascript si vous voulez m'écrire") - robot
Dans les cas 1 et 2, la page sera affichée même si elle n'est pas syntaxiquement correcte (c'est d'ailleurs une des forces du HTML d'afficher même si c'est invalide) et dans le cas 3, sa visite n'est pas désirée.
Si je récupère votre page en local (comme l'a décrit Olivier M), que j'analyse le code JS, il doit y avoir moyen de créer une page parfaitement utilisable sans JS, non ?
-- Michaël DENIS
Denis Beauregard a écrit :
Mais on s'en fout ! Je veux dire qu'on a 3 cas de figure :
- usage humain avec javascript -> il peut envoyer un message
- usage humain sans javascript -> il ne peut pas envoyer un message
(donc, si on utilise cette méthode, il faudrait remplacer le champ
"texte" par un "activez le javascript si vous voulez m'écrire")
- robot
Dans les cas 1 et 2, la page sera affichée même si elle n'est pas
syntaxiquement correcte (c'est d'ailleurs une des forces du HTML
d'afficher même si c'est invalide) et dans le cas 3, sa visite n'est
pas désirée.
Si je récupère votre page en local (comme l'a décrit Olivier M), que
j'analyse le code JS, il doit y avoir moyen de créer une page
parfaitement utilisable sans JS, non ?
Mais on s'en fout ! Je veux dire qu'on a 3 cas de figure :
- usage humain avec javascript -> il peut envoyer un message - usage humain sans javascript -> il ne peut pas envoyer un message (donc, si on utilise cette méthode, il faudrait remplacer le champ "texte" par un "activez le javascript si vous voulez m'écrire") - robot
Dans les cas 1 et 2, la page sera affichée même si elle n'est pas syntaxiquement correcte (c'est d'ailleurs une des forces du HTML d'afficher même si c'est invalide) et dans le cas 3, sa visite n'est pas désirée.
Si je récupère votre page en local (comme l'a décrit Olivier M), que j'analyse le code JS, il doit y avoir moyen de créer une page parfaitement utilisable sans JS, non ?
-- Michaël DENIS
Michael DENIS
Olivier Miakinen a écrit :
Un compromis acceptable est de filtrer les sauts de ligne dans ces champs s'ils viennent de l'extérieur.
Pourquoi se limiter à la vérification des sauts de lignes ? Pour ma part, je vérifie systématiquement que les champs reçus ne sont pas plus longs par exemple que ceux donnés dans le formulaire d'origine (maxlength), et également, et c'est non négligeable dans les faits, que le retour des listbox est conforme. S'ajoute pour certains une vérification de contenu.
Et je n'ai plus guère qu'une ou deux tentatives successives de façon épisodique.
-- Michaël DENIS
Olivier Miakinen a écrit :
Un compromis acceptable est de filtrer les sauts
de ligne dans ces champs s'ils viennent de l'extérieur.
Pourquoi se limiter à la vérification des sauts de lignes ? Pour ma
part, je vérifie systématiquement que les champs reçus ne sont pas plus
longs par exemple que ceux donnés dans le formulaire d'origine
(maxlength), et également, et c'est non négligeable dans les faits, que
le retour des listbox est conforme. S'ajoute pour certains une
vérification de contenu.
Et je n'ai plus guère qu'une ou deux tentatives successives de façon
épisodique.
Un compromis acceptable est de filtrer les sauts de ligne dans ces champs s'ils viennent de l'extérieur.
Pourquoi se limiter à la vérification des sauts de lignes ? Pour ma part, je vérifie systématiquement que les champs reçus ne sont pas plus longs par exemple que ceux donnés dans le formulaire d'origine (maxlength), et également, et c'est non négligeable dans les faits, que le retour des listbox est conforme. S'ajoute pour certains une vérification de contenu.
Et je n'ai plus guère qu'une ou deux tentatives successives de façon épisodique.
-- Michaël DENIS
Laurent vilday
Olivier Masson a écrit :
Laurent vilday a écrit :
J'ai du mal à comprendre le raisonnement. On est pas tout à fait dans la même logique qu'un logiciel client ou serveur qu'il *faut* mettre à jour suite à la correction de certains bugs et autres trous de sécurité. Non, là on est dans l'évolution non désirée et non indispensable d'un langage.
Pas envie de rentrer dans un troll, pas le temps. Simplement, tu as du loupé un truc : le moment où on t'apprenais que php était utilisé, à l'instar de perl, python (et ruby) pour le développement web.
Ca veut dire qqchose ça ?
Donc, pour résumer, on ne se comprends pas, on ne parle apparemment pas de la même chose et dés ta première réponse tu passes par l'attaque trollesque (mais bien sur) pour finir par des attaques personnelles.
Donc ok, j'abandonne, je n'essaierais plus de te comprendre. Pourtant j'aimerais bien mais tant pis puisque je constate qu'il est impossible d'avoir une conversation.
-- laurent
Olivier Masson a écrit :
Laurent vilday a écrit :
J'ai du mal à comprendre le raisonnement. On est pas tout à fait dans
la même logique qu'un logiciel client ou serveur qu'il *faut* mettre à
jour suite à la correction de certains bugs et autres trous de
sécurité. Non, là on est dans l'évolution non désirée et non
indispensable d'un langage.
Pas envie de rentrer dans un troll, pas le temps.
Simplement, tu as du loupé un truc : le moment où on t'apprenais que php
était utilisé, à l'instar de perl, python (et ruby) pour le
développement web.
Ca veut dire qqchose ça ?
Donc, pour résumer, on ne se comprends pas, on ne parle apparemment pas
de la même chose et dés ta première réponse tu passes par l'attaque
trollesque (mais bien sur) pour finir par des attaques personnelles.
Donc ok, j'abandonne, je n'essaierais plus de te comprendre. Pourtant
j'aimerais bien mais tant pis puisque je constate qu'il est impossible
d'avoir une conversation.
J'ai du mal à comprendre le raisonnement. On est pas tout à fait dans la même logique qu'un logiciel client ou serveur qu'il *faut* mettre à jour suite à la correction de certains bugs et autres trous de sécurité. Non, là on est dans l'évolution non désirée et non indispensable d'un langage.
Pas envie de rentrer dans un troll, pas le temps. Simplement, tu as du loupé un truc : le moment où on t'apprenais que php était utilisé, à l'instar de perl, python (et ruby) pour le développement web.
Ca veut dire qqchose ça ?
Donc, pour résumer, on ne se comprends pas, on ne parle apparemment pas de la même chose et dés ta première réponse tu passes par l'attaque trollesque (mais bien sur) pour finir par des attaques personnelles.
Donc ok, j'abandonne, je n'essaierais plus de te comprendre. Pourtant j'aimerais bien mais tant pis puisque je constate qu'il est impossible d'avoir une conversation.
-- laurent
Laurent vilday
Mickaël Wolff a écrit :
Laurent vilday a écrit :
J'en doute pas, j'ai pas la prétention d'être un super pro. M'enfin merci quand même ...
C'est vrai que j'y suis allé un peu fort. Je te présentes mes excuses.
Pas de problème en fait, c'est moi qui m'exprime mal et ai tendance à rendre les choses confuses, sans rentrer dans les détails de mon tempérament pourri.
Parce que tu fais migrer des applications sans que tes clients te payent le moindre denier ? Dès qu'une faille ou un bug est exposé, évidemment que tous les contrats de maintenance de la planète devraient exiger la rectification du problème. Quitte à faire migrer les applicatifs serveurs lorsque nécessaire. Mais une application une fois en production et recettée, ben les contrats stipulent bien qu'il faut plus y toucher.
Ça c'est un gros défaut dans le modèle des société de développement. Tu fais payer un développement spécifique, mais tu ne t'assures pas qu'en cas de changement technologique majeur, le client doive mettre la main à la poche.
Exact j'y avais jamais pensé (pas trop ma partie faut dire), j'en ai profité pour remonter ce problème au service concerné.
Merci du "tips", même si :D j'ai eu le droit au téléphone d'un "rahh, tu fais encore chier"
Et hop, on retombe dans le concept du tout objet c'est magique. C'est tellement professionnel de coder en tout objet, c'est bien sûr.
La preuve, tout le monde essaye de le faire en javascript ;)
LOL, j'en dirais pas plus, mais très LOL quand même :)
Mais est-ce que tes clients seraient prêts à te payer une redevance plutôt qu'un forfait pour leurs applications web ? Et ainsi assurer l'évolution ?
Je sais pas trop si ce modèle de location du produit est accepté par les PME. J'en ai pas trop l'impression, mais encore une fois c'est pas ma partie alors je sais je suis loin de connaitre la réalité des choses.
J'ai plus le sentiment que les PME veulent à tout prix être propriétaires du produit. Ils sont prêts à dématérialiser leurs données mais le logiciel ça me semble plus dur. A défaut de pouvoir toucher j'ai l'impression qu'elles veulent à tout pris maitriser quelque chose. Ce qui est quand même une vaste illusion.
-- laurent
Mickaël Wolff a écrit :
Laurent vilday a écrit :
J'en doute pas, j'ai pas la prétention d'être un super pro. M'enfin
merci quand même ...
C'est vrai que j'y suis allé un peu fort. Je te présentes mes excuses.
Pas de problème en fait, c'est moi qui m'exprime mal et ai tendance à
rendre les choses confuses, sans rentrer dans les détails de mon
tempérament pourri.
Parce que tu fais migrer des applications sans que tes clients te
payent le moindre denier ? Dès qu'une faille ou un bug est exposé,
évidemment que tous les contrats de maintenance de la planète
devraient exiger la rectification du problème. Quitte à faire migrer
les applicatifs serveurs lorsque nécessaire. Mais une application une
fois en production et recettée, ben les contrats stipulent bien qu'il
faut plus y toucher.
Ça c'est un gros défaut dans le modèle des société de développement.
Tu fais payer un développement spécifique, mais tu ne t'assures pas
qu'en cas de changement technologique majeur, le client doive mettre la
main à la poche.
Exact j'y avais jamais pensé (pas trop ma partie faut dire), j'en ai
profité pour remonter ce problème au service concerné.
Merci du "tips", même si :D j'ai eu le droit au téléphone d'un "rahh, tu
fais encore chier"
Et hop, on retombe dans le concept du tout objet c'est magique. C'est
tellement professionnel de coder en tout objet, c'est bien sûr.
La preuve, tout le monde essaye de le faire en javascript ;)
LOL, j'en dirais pas plus, mais très LOL quand même :)
Mais est-ce que tes clients seraient prêts à te payer une redevance
plutôt qu'un forfait pour leurs applications web ? Et ainsi assurer
l'évolution ?
Je sais pas trop si ce modèle de location du produit est accepté par les
PME. J'en ai pas trop l'impression, mais encore une fois c'est pas ma
partie alors je sais je suis loin de connaitre la réalité des choses.
J'ai plus le sentiment que les PME veulent à tout prix être
propriétaires du produit. Ils sont prêts à dématérialiser leurs données
mais le logiciel ça me semble plus dur. A défaut de pouvoir toucher j'ai
l'impression qu'elles veulent à tout pris maitriser quelque chose. Ce
qui est quand même une vaste illusion.
J'en doute pas, j'ai pas la prétention d'être un super pro. M'enfin merci quand même ...
C'est vrai que j'y suis allé un peu fort. Je te présentes mes excuses.
Pas de problème en fait, c'est moi qui m'exprime mal et ai tendance à rendre les choses confuses, sans rentrer dans les détails de mon tempérament pourri.
Parce que tu fais migrer des applications sans que tes clients te payent le moindre denier ? Dès qu'une faille ou un bug est exposé, évidemment que tous les contrats de maintenance de la planète devraient exiger la rectification du problème. Quitte à faire migrer les applicatifs serveurs lorsque nécessaire. Mais une application une fois en production et recettée, ben les contrats stipulent bien qu'il faut plus y toucher.
Ça c'est un gros défaut dans le modèle des société de développement. Tu fais payer un développement spécifique, mais tu ne t'assures pas qu'en cas de changement technologique majeur, le client doive mettre la main à la poche.
Exact j'y avais jamais pensé (pas trop ma partie faut dire), j'en ai profité pour remonter ce problème au service concerné.
Merci du "tips", même si :D j'ai eu le droit au téléphone d'un "rahh, tu fais encore chier"
Et hop, on retombe dans le concept du tout objet c'est magique. C'est tellement professionnel de coder en tout objet, c'est bien sûr.
La preuve, tout le monde essaye de le faire en javascript ;)
LOL, j'en dirais pas plus, mais très LOL quand même :)
Mais est-ce que tes clients seraient prêts à te payer une redevance plutôt qu'un forfait pour leurs applications web ? Et ainsi assurer l'évolution ?
Je sais pas trop si ce modèle de location du produit est accepté par les PME. J'en ai pas trop l'impression, mais encore une fois c'est pas ma partie alors je sais je suis loin de connaitre la réalité des choses.
J'ai plus le sentiment que les PME veulent à tout prix être propriétaires du produit. Ils sont prêts à dématérialiser leurs données mais le logiciel ça me semble plus dur. A défaut de pouvoir toucher j'ai l'impression qu'elles veulent à tout pris maitriser quelque chose. Ce qui est quand même une vaste illusion.
