OVH Cloud OVH Cloud

Formulaires spammés

57 réponses
Avatar
docanski
Bonjour,

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 :

if(armo.Avis.value == "http://")
armo.Avis.focus();
return false;}

(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/

10 réponses

2 3 4 5 6
Avatar
Olivier Masson
Olivier Miakinen a écrit :

Oui, c'est ce que j'ai lu. Mais il vaut mieux faire comme si ça ne
l'était pas, on ne sait jamais (vieille version, bug, etc.).



Certes, mais il me semble que le support de PHP4 s'arrête complètement
ces jours-ci.
Ne pas passer à PHP5 est donc assez stupide (ce qui n'empêche pas, tu as
bien raison, de coder aussi proprement que possible.)
Avatar
Laurent vilday
Olivier Masson a écrit :
Olivier Miakinen a écrit :

Oui, c'est ce que j'ai lu. Mais il vaut mieux faire comme si ça ne
l'était pas, on ne sait jamais (vieille version, bug, etc.).



Certes, mais il me semble que le support de PHP4 s'arrête complètement
ces jours-ci.
Ne pas passer à PHP5 est donc assez stupide (ce qui n'empêche pas, tu as
bien raison, de coder aussi proprement que possible.)



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.

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 ?

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 ?

J'ai de nombreux serveurs (et services) qui tournent sous PHP4 et il
n'est pas prévu une migration vers PHP5, tout simplement parce que on ne
va pas ni recoder ni dépenser des hommes/heures pour faire une
transition qui ne sert à rien.

Et c'est pas comme si on parlait de PHP6 avec enfin sa gestion unicode
correcte ou encore d'une brique qui marcherait mal qu'il faudrait
absolument remplacer.

Non, là il est question de PHP5 (Zend engine 2), une version qui
n'apporte rien de bien concret par rapport à PHP4 (Zend engine 1) si ce
n'est un modèle objet pas très utile et des changements dans l'ordre et
les types de paramètres autorisés des fonctions. C'est pas parce que la
programmation OOP existe que tout doit être OOP.

Et non, j'en suis bien désolé, mais la disparition du support de Mysql
par défaut *et* la réécriture du modèle objet de PHP5 n'en fait pas une
version exceptionnelle et encore moins une version indispensable. Le
modèle objet PHP4 nous suffit largement pour l'utilisation qu'il en est
faite et ça fait bien des années qu'on n'utilise plus Mysql.

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.

--
laurent
Avatar
Sergio
Il se trouve que Laurent vilday a formulé :

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 ?



Que, à moins de coder avec les deux pieds gauche, un code pour PHP 4
passe sous PHP 5. Donc il est *totalement* inutile de maintenir les
deux versions.

La coexistence des deux versions a duré suffisamment longtemps (trop à
mon goût), pour avoir eu le temps de corriger les codes incompatibles.

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Avatar
Pierre Goiffon
Laurent vilday wrote:
Certes, mais il me semble que le support de PHP4 s'arrête complètement
ces jours-ci.
Ne pas passer à PHP5 est donc assez stupide (ce qui n'empêche pas, tu
as bien raison, de coder aussi proprement que possible.)



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.



Un interpréteur présente aussi des failles de sécurité !
Voir par exemple la fiche sur Secunia pour PHP 4.4.x :
http://secunia.com/product/5768/

Et ce sont bien des produits serveurs qui sont les plus dangereux, car
au "centre" du SI...
Avatar
Laurent vilday
Sergio a écrit :
Il se trouve que Laurent vilday a formulé :

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 ?



Que, à moins de coder avec les deux pieds gauche, un code pour PHP 4
passe sous PHP 5. Donc il est *totalement* inutile de maintenir les deux
versions.



Faux, totalement faux malheureusement.
PHP5 et PHP4 ne sont pas 100% compatibles.
<http://www.php.net/manual/fr/migration5.incompatible.php>

Je suis d'accord que grosso modo, la transition est supposée se passer
sans douleur, surtout que ça fait bien longtemps que PHP5 est là.

Mais je maintiens que passer de PHP4 à PHP5 n'est pas obligatoire ni
indispensable. Je ne me vois pas investir le moindre homme/heure dans
tout ce qui existe déjà (et maintenu) en PHP4. Car transformer le
langage d'un outils en production c'est obligatoirement l'investissement
d'hommes et de temps pour vérifier complètement que rien n'a été cassé.

Je dirais que :
- *oui*, pour tout nouveau développement je suis d'accord autant
oublier PHP4. Perso ça fait 1 an et demi qu'il est abandonné pour les
nouveaux projets chez nous.
- mais *non*, pour tout migrer, puisque certains outils *doivent*
continuer à être maintenu en production et pourtant ils sont en version
PHP4.

Ca ne rend pas plus les outils maintenu en PHP4 ni les devs qui les
maintiennent et les font évoluer selon les besoin, des personnes
stupides. C'était le "Ne pas passer à PHP5 est donc assez stupide" de
Olivier Masson qui m'avait fait sortir de ma léthargie.

--
laurent
Avatar
Laurent vilday
Pierre Goiffon a écrit :
Laurent vilday wrote:
Certes, mais il me semble que le support de PHP4 s'arrête
complètement ces jours-ci.
Ne pas passer à PHP5 est donc assez stupide (ce qui n'empêche pas, tu
as bien raison, de coder aussi proprement que possible.)



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.



Un interpréteur présente aussi des failles de sécurité !
Voir par exemple la fiche sur Secunia pour PHP 4.4.x :
http://secunia.com/product/5768/



Mouais.

5 unpatched, assez facile de savoir si le code développé est impacté ou
non :

1) Interbase (affecte PHP5 aussi)
<http://secunia.com/advisories/24529/>

2) snmpget(), session_decode()
<http://secunia.com/advisories/24440/>

3) WIN only, dbopen() quand MSSQL installé (affecte PHP5 aussi)
<http://secunia.com/advisories/24353/>

4) symlinks (affecte PHP5 aussi)
<http://secunia.com/advisories/22235/>

5) mb_send_mail() (affecte PHP5 aussi)
<http://secunia.com/advisories/18694/>

Pas vraiment de quoi fouetter un chat, et pas de quoi imposer une
migration PHP5. Puisque sur les 5 il y en a 4 (80%) qui affectent aussi
PHP5 donc ce ne sera pas plus "secure" en PHP5.

Et ce sont bien des produits serveurs qui sont les plus dangereux, car
au "centre" du SI...



Je ne suis, encore une fois, pas totalement d'accord. Là on parle d'un
langage, pas d'un logiciel accessible par n'importe qui en dehors du
serveur à travers le combo IP/port.

Pour pouvoir essayer d'utiliser les failles il faut déjà trouver la page
PHP (sans connaître ni le code ni la structure) qui utilise la ou les
fonctions qu'on veut exploiter.

Ca me semble nettement plus dur à accomplir que d'aller envoyer des
paquets IP foireux à un Outlook Exchange par exemple.

Je maintiens donc, la migration PHP4 vers PHP5 n'est pas indispensable
pour l'existant.

A moins d'avoir un besoin irraisonné pour le nouveau modèle objet parce
que c'est so hype de faire de l'OOP PHP5.

--
laurent
Avatar
Denis Beauregard
Le Tue, 05 Aug 2008 09:10:05 +0200, Olivier Miakinen
<om+ écrivait dans fr.comp.infosystemes.www.auteurs:

Le 05/08/2008 02:59, Denis Beauregard a écrit :

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



[...]

Il suffit de faire afficher l'adresse seulement si la souris
est au dessus du lien mailto: Sinon, on affiche autre chose.



Je suis désolé, mais tu réponds à côté du sujet. Il n'y a aucune adresse
de courriel sur la page en question, mais un formulaire. Les spammeurs
ne récupèrent donc aucune adresse sur cette page, mais ils spamment par
son intermédiaire.



Mais si on utilise la même méthode ? Le bouton "envoyer"
n'apparaissant que si la souris est au dessus ?


Denis
Avatar
Mickaël Wolff
Denis Beauregard a écrit :

Mais si on utilise la même méthode ? Le bouton "envoyer"
n'apparaissant que si la souris est au dessus ?



On va le répéter une dernière fois : le javascript n'est pas
interprété par les robots.

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



C'est bien là que tu fais erreur, PHP n'est pas un langage à
proprement parler. PHP est un logiciel fournissant un framework et un
langage de programmation interne. Le support de la version 4 de ce
logiciel s'arrête, ce qui signifie que les éventuelles failles de
sécurité de seront pas corrigées, et que le conserver en production
deviendra dangereux.


Ceux qui font du C sont-ils plus stupides que ceux qui font du
C++ ?



Le C++ n'a rien à voir avec le C. Effectivement le C++ s'est présenté
comme une évolution du C, mais quand on en a fait suffisamment on sait
que les deux langages n'ont en commun qu'une relative compatibilité des
modules. Bref, en C et en C++ aussi il y a des version de la norme, puis
des implémentation. Faire du C façon K&R plutôt que du C99 est
équivalent à faire du PHP 4 plutôt que PHP5 : c'est regrettable. C'est
se mettre en marge des compilateurs modernes, ignorer les évolutions
technologiques du langages, etc.

Mais je ne vois pas le problème à utiliser des langages qui sont
inégalés, tels que le Cobol, le Fortran, le C et le C++, sous prétexte
qu'ils sont vieux. Au contraire, leur maturité fait qu'ils sont des
premiers choix. Mais la différence avec le PHP4, c'est qu'ils sont
maintenus et en évolution.


Parce que je fait l'impasse sur la langage D, ça me rendrait plus
stupide que ceux qui parient sur ce langage ?



Non, mais croire que D est le successeur de C ou C++ est ma fois bien
naïf.


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 ?



Si les scripts ne sont pas essentiels, c'est une transition
éventuelle. Mais il ne faudra pas pleurer si une faille béante apparaît,
que personne ne souhaite réparer, et que par précaution l'ensemble des
fournisseurs de serveurs retirent la fonctionnalité.


J'ai de nombreux serveurs (et services) qui tournent sous PHP4 et il
n'est pas prévu une migration vers PHP5, tout simplement parce que on ne
va pas ni recoder ni dépenser des hommes/heures pour faire une
transition qui ne sert à rien.



Cette remarque dénote un profond manque de professionnalisme. Cela
fait bien deux ans que les développeurs de PHP ont annoncé la fin de la
maintenance de PHP4 au profit de PHP5. Il y avait donc largement le
temps de répartir les migrations.

Mais si la migration est impossible, c'est que les temps.homme
dépensés ne le furent pas à bon escient.


Et c'est pas comme si on parlait de PHP6 avec enfin sa gestion unicode
correcte ou encore d'une brique qui marcherait mal qu'il faudrait
absolument remplacer.



Étant donné que PHP6 devrait bientôt sortir, commencer à migrer vers
PHP5 en profitant des fonctionnalités objet minimales ne serait pas un
moindre mal.


Non, là il est question de PHP5 (Zend engine 2), une version qui
n'apporte rien de bien concret par rapport à PHP4 (Zend engine 1) si ce
n'est un modèle objet pas très utile et des changements dans l'ordre et
les types de paramètres autorisés des fonctions. C'est pas parce que la
programmation OOP existe que tout doit être OOP.



C'est une version qui apporte l'assurance d'être maintenue.


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 pourras organiser la maintenance de PHP4 si ça t'amuse ;) Simple
question, tu continue d'utiliser Apache 1.3 ? Et tu utilises Paradox
pour stocker les données (ça c'est pour te taquiner) ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Avatar
Denis Beauregard
Le Tue, 05 Aug 2008 15:57:43 +0200, Mickaël Wolff
écrivait dans
fr.comp.infosystemes.www.auteurs:

Denis Beauregard a écrit :

Mais si on utilise la même méthode ? Le bouton "envoyer"
n'apparaissant que si la souris est au dessus ?



On va le répéter une dernière fois : le javascript n'est pas
interprété par les robots.



Alors, il suffit tout bonnement de faire apparaître le bouton
"envoyer" seulement en javascript et plus aucun robot n'ira sur
place...


Denis

P.S. On m'a toutefois fait la démonstration du contraire. Il y a
des robots qui utilisent IE pour lire les pages.
2 3 4 5 6