Formulaires spammés

Denis Beauregard a écrit :

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

Et comment font ceux qui ont le javascript de désactivé ? :p

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

C'est possible, mais dans ce cas, le robot peut désactiver a sa
convenance le javascript.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

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

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é !

Mouais.

(...)

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.

Je ne prononcerai pas du tout sur l'utilité de migrer de PHP4 à 5,
n'étant pas assez calé sur ce sujet précis. Je réagissais plutôt au ton
que tu employais par rapport à la sécurité d'un outil de traitement serveur.

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.

Les admins des serveurs Web (et qui plus est le rssi de la société s'il
existe) n'a aucune idée de ce que contient le code posé sur le serveur.
De ce point de vue, ils laissent donc une machine serveur (avec tout ce
que ça veut dire pour la sécurité par rapport au firewall) en "libre
service pour déposer du code" : non seulement il y a des possibilités de
failles mais en plus possibilité d'en ajouter de nouvelles avec des
applications mal écrites, et ce sur une machine qui a des accès
privilégiés !

Réaliser une intrusion sur un poste de travail n'est pas très
intéressant, ledit poste ne disposant normalement que d'accès limités
sur le réseau... et pouvant être isolé rapidement sur détection
d'intrusion (éventuellement automatisée, il y a des outils dédiés à cela
maintenant, je ne sais pas si ça fonctionne au poil ?)
Sur un serveur ça va changer beaucoup de choses ! Et d'un point de vue
pragmatique les serveurs sont des postes comme les autres, les failles
exploitables pour déposer un code sont donc les mêmes. Mais une fois
rentré dedans on n'aura pas du tout les mêmes accès !

En tant que développeur, j'ai rencontré nombre d'admins très
chatouilleux avec leurs serveurs Web, et je les comprend aisément !
Lorsque l'on installe une application sur un serveur on a souvent
beaucoup plus de choses à demander que pour une application sur un
"simple" poste de travail.

Le Tue, 05 Aug 2008 16:50:20 +0200, Mickaël Wolff
<mickael.wolff@laposte.net> écrivait dans
fr.comp.infosystemes.www.auteurs:

Denis Beauregard a écrit :

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

Et comment font ceux qui ont le javascript de désactivé ? :p

Je disais pourtant : "Si tu acceptes l'idée d'imposer le JS à tes
visiteurs"

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

C'est possible, mais dans ce cas, le robot peut désactiver a sa
convenance le javascript.

Personnellement, je prendrais pour acquis qu'un robot n'utilisera
pas le javascript.

Sur mon site, les robots spammeurs vont plutôt installer leur saleté
dans les commentaires du wiki. Mais je vais finir par enlever ce
wiki.


Denis

Denis Beauregard a écrit :

Le Tue, 05 Aug 2008 15:57:43 +0200, Mickaël Wolff
<mickael.wolff@laposte.net> é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...

Il suffit d'avoir un robot qui lise le formulaire et envoie un
"Submit", même s'il n'y a pas de bouton...

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Mickaël Wolff 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.

C'est bien là que tu fais erreur,

J'en doute pas une seconde, j'en fais plein tous les jours, c'est pas
une première :)

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.

J'avoue ne pas comprendre en quoi PHP n'est pas un langage à proprement
parler.

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.

Transition *éventuelle*, mais pas *stupide* de rester sur une telle
version *fonctionnelle* en production.

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

Que personne ne souhaite réparer ? Encore une fois je ne comprend pas
pas trop mais certainement parce que je ne sais pas de qui/quoi on parle
je pense (les devs, les admins, les FAIs, les clients, ... ?). Si une
faille apparait évidemment qu'il faut s'en occuper et solutionner.

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.

J'en doute pas, j'ai pas la prétention d'être un super pro. M'enfin
merci quand même ...

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.

???

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.

Et je n'ai pas connaissance d'une seule société - à but lucratif,
société de consommation et globalisation oblige - qui irait investir des
Hommes/Heures dans une migration complète d'un système qui fonctionne.
Système en production, pas une nouvelle création, je parle de milliers
de lignes de codes existants depuis des mois voir des années sans
problèmes majeurs.

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

On est vraiment pas sur la même longueur d'onde, je ne suis certainement
pas assez professionnel pour comprendre certaines subtilités. Je ne vois
pas comment on pourrait justifier une migration de l'existant de PHP4 à
PHP5 sur la base de tes arguments.

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.

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.

Pourquoi migrer une application PHP4 qui tourne vers PHP5 sous prétexte
de "fonctionnalités objet minimales" qui ne sont pas utilisées dans
l'application existante ?

Depuis le début je ne parle pas de créer de nouvelles choses en PHP4
aujourd'hui en fin 2008, ça fait bien longtemps que j'ai imposé PHP5
pour les nouveaux projets.

Je parle d'applications existantes en production et totalement bouclée.
Lorsque une demande d'évolution est commandée, ben je suis désolé mais
les lignes de codes ajoutées/modifiées resteront en PHP4, et ça pour la
durée de vie de ces applications.

Rien ne vient justifier une migration vers PHP5 ou autre, bien au
contraire. On touche pas comme ça à un produit payé. Y'a des contrats à
respecter, du code en production ça se manipule pas comme ça selon le
bon vouloir du moment. Que PHP4 soit abandonné ou pas.

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.

Argument, IMO, invalide concernant le code déjà existant, ce dont je
parle depuis le début.

Tu pourras organiser la maintenance de PHP4 si ça t'amuse ;)

J'ai jamais dit que c'était fun, ni dit qu'il fallait rester à PHP4.
Juste que je dis et redis que je ne vois pas en quoi c'est *stupide* de
ne pas passer à PHP5 lorsque les applications en PHP4 fonctionnent très
bien et n'ont pas de failles connues à ce jour.

M'enfin, on peut pas se comprendre, je manque cruellement de
professionnalisme pour avoir le recul suffisant. Tiens, d'ailleurs, j'ai
le droit de continuer à m'exprimer sur un tel sujet malgrès mon "profond
manque de professionnalisme" ?

Pfff

--
laurent

Le Tue, 05 Aug 2008 18:06:37 +0200, Laurent vilday <mokhet@mokhet.com>
écrivait dans fr.comp.infosystemes.www.auteurs:

Et je n'ai pas connaissance d'une seule société - à but lucratif,
société de consommation et globalisation oblige - qui irait investir des
Hommes/Heures dans une migration complète d'un système qui fonctionne.

C'est pourtant à peu près ce qui s'est produit en passant de Win 98 à
XP et maintenant à Vista... Le plus hallucinant, dans ce cas, c'est
que le nombre de corrections de sécurité de XP est supérieur à celui
de 98 (qui est donc moins dangereux).


Denis

Le Tue, 05 Aug 2008 17:59:55 +0200, Sergio
<laposte@serge.delbono.net.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:

Denis Beauregard a écrit :

Le Tue, 05 Aug 2008 15:57:43 +0200, Mickaël Wolff
<mickael.wolff@laposte.net> é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...

Il suffit d'avoir un robot qui lise le formulaire et envoie un
"Submit", même s'il n'y a pas de bouton...

À quelle adresse ? Si le champ "action" n'est là que si le javascript
est actif, il me semble impossible d'envoyer le formulaire.


Denis

Denis Beauregard a écrit :

À quelle adresse ? Si le champ "action" n'est là que si le javascript
est actif, il me semble impossible d'envoyer le formulaire.

Si l'attribut action n'est pas disponible, le document HTML est
invalide.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Le Tue, 05 Aug 2008 20:24:24 +0200, Mickaël Wolff
<mickael.wolff@laposte.net> écrivait dans
fr.comp.infosystemes.www.auteurs:

Denis Beauregard a écrit :

À quelle adresse ? Si le champ "action" n'est là que si le javascript
est actif, il me semble impossible d'envoyer le formulaire.

Si l'attribut action n'est pas disponible, le document HTML est
invalide.

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.

La protection contre le spam doit avant le purisme de la syntaxe dans
mon livre.


Denis

Laurent vilday a écrit :

J'en doute pas une seconde, j'en fais plein tous les jours, c'est pas
une première :)

Comme tout le monde :)

J'avoue ne pas comprendre en quoi PHP n'est pas un langage à proprement
parler.

C'est du pinaillage. Les habitués de la liste savent que j'aime
pinailler. PHP est un logiciel, comprenant un langage de programmation
et des bibliothèques. Parler du langage PHP c'est faire un raccourci,
puisque nous devrions dire que nous programmons dans le langage de PHP.
Mais je te l'accorde, c'est lourd ;)

Transition *éventuelle*, mais pas *stupide* de rester sur une telle
version *fonctionnelle* en production.

C'est parce que le logiciel PHP4 risque d'avoir des soucis de
sécurité, et que ces problèmes ne seront plus corrigés. En cas de
problème grave, tu risque de devoir soit corriger toi-même et maintenir
une version rebelle, soit migrer dans l'urgence et la panique vers PHP5
ou 6.

Mais c'est vrai que c'est improbable.

Que personne ne souhaite réparer ? Encore une fois je ne comprend pas
pas trop mais certainement parce que je ne sais pas de qui/quoi on parle
je pense (les devs, les admins, les FAIs, les clients, ... ?). Si une
faille apparait évidemment qu'il faut s'en occuper et solutionner.

Je pensais aux développeurs du projet PHP. Mais je pense aussi que si
un trou béant apparaît, quelqu'un résoudra le problème. C'est du
logiciel libre quand même.
Mais la résolution variera furieusement selon celui qui s'enquiert du
problème :
- les devs : si ce sont les tiens (ou toi), pas de soucis
- les admins : suppression de PHP4, on ne s'emmerde pas avec les
vieilleries :-D
- les FAI : la solution de leurs devs ou de leurs admins, il faudra
prier.
- les clients : ils te feront un chèque (haha)

:)

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.

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.

Et je n'ai pas connaissance d'une seule société - à but lucratif,
société de consommation et globalisation oblige - qui irait investir des
Hommes/Heures dans une migration complète d'un système qui fonctionne.
Système en production, pas une nouvelle création, je parle de milliers
de lignes de codes existants depuis des mois voir des années sans
problèmes majeurs.

Oui mais tu risques d'avoir un problème majeur si tu ne suis pas
l'évolution technologique du logiciel que tu utilises. Ce qui peut te
coûter plus chère. Maintenant, ça dépend comment tu fais payer tes
clients (à la prestation ou à la redevance).

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

Pourquoi

[...]

Que PHP4 soit abandonné ou pas.

Ce qui signifie que tu vas maintenir une version de PHP4 maison, si
je comprends bien ?

Tu pourras organiser la maintenance de PHP4 si ça t'amuse ;)

J'ai jamais dit que c'était fun, ni dit qu'il fallait rester à PHP4.
Juste que je dis et redis que je ne vois pas en quoi c'est *stupide* de
ne pas passer à PHP5 lorsque les applications en PHP4 fonctionnent très
bien et n'ont pas de failles connues à ce jour.

M'enfin, on peut pas se comprendre, je manque cruellement de
professionnalisme pour avoir le recul suffisant. Tiens, d'ailleurs, j'ai
le droit de continuer à m'exprimer sur un tel sujet malgrès mon "profond
manque de professionnalisme" ?

Rha, j'y suis certes allé fort. Mais ce que je pointais c'était le
fait que tu faisais prendre un risque à tes clients, en maintenant leurs
développements sur une version qui risque de devenir obsolète, non pas
au niveau des fonctionnalités et des performances, mais au niveau de la
sécurité.

Encore une fois je te présente mes excuses, pour avoir mis en doute
ton professionnalisme. Je ne voyais pas ce qui pouvait justifier le
maintient de développement en PHP4. La nécessité de maintenir des
développements qui ne sont plus évolutifs (car uniquement maintenues)
est une bonne raison.

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 ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org