Yop
 
Je me demande simplement quel est la meilleur méthode pour éviter qu'un petit malin fasse F5 F5 F5 F5 après avoir posté un message ... j'ai pensé mettre un champ hidden qui passe à 0 une fois le message posté mais si il est pas trop con il le trouve sinon bah une variable de session mais je ne sais pas si c'est vraiment terrible
 
EDIT : ou alors faire une recherche dans la base avec les infos postées et si trouvé alors on refuse ?
 
Merci
 
Darx

bloquer les nouveaux posts pour chaque triplet ip du visiteur / topic / laps de temps ( par exemple 30 secondes)

euh ouaip mais en fait c'est plutôt un guest book donc il suffit de mettre un nom et un message pour poster... y a pas de comptes utilisateurs...

 
IP + texte indentique 3 * fois de suite = NON.  

une redirection apres le traitement

beuar après 2 secondes de réfléchissement un champ time dans la base de donnée et un controle à la con lors du post et si - de 30 secondes alors non ...  
 
Merci
 
EDIT désolé pour ce post inutil au final vu qu'en utilisant un minimum son cerveau ça marche ...  

Salut,
 
je résuscite ce topic car je ne trouve pas de solutions à mon prob !
 
Je veux aussi éviter le flood massif mais pas sur un script qui fait un insert/update sur une base de données !
 
Exemple : un formulaire de mail pour contacter les webmasters, dispo pour tous visiteurs.
Si le gars fait F5, F5, F5, F5, F5 il m'envoie 6 mails !
 
Le prob peut arriver dans d'autres cas de figure évidemment mais celui-là est le plus pénalisant !
 
J'ai tenté un redirect avec un header('location: index.php') ; mais si je fais refresh, ça renvoie qd même le formulaire donc je suis mort
J'aimerai faire quelque chose en script serveur, pas un redirect javascript car dans le cas où mon visiteur a désactivé ses scripts clients, je suis re-mort
 
Le forum gère ça très bien (même s'il y a une requête sur une table). Si on fait un F5 après avoir posté un message, on ne nous propose JAMAIS de re-valider un formulaire. C'est à ça que j'aimerai arriver.
 
En regardant dans le source de cette page, je vois :
 

 
Est-ce que ça peut être la réponse à mon problème ?
Merci
 
a+
 
 

En tête de page :

dans le traitement de formulaire :

30 c'est le temps en secondes pendant lequel il est impossible de poster à nouveau.

Je pense qu'il faudrait placer tous ce qui  caracterise un poste (titre, message, etc...) en session et le topic posté ne peut pas être identique à celui qui est enregistré en session.
Il y a la page intermediaire qui vérouille la possibilité de posté depuis cette meme page apres enregistrement. Le deverouillage s'éffectura lorsque la page revient sur une autre page.

ca marcherait ca ?
 
 
créer une variable de session aléatoire.
lors de l'affichage du formulaire : placer cette variable dans le formulaire en hidden.
 
quand on "submit" le formulaire : vérifier si la variable hidden est la même que celle en session.
si oui, faire ce qu'on a à faire ET changer la variable de session.
si non, exit();

mon antiflood est plus simple, non ?

Oui sa peut être bien cela evite non seulement le double postage (dans la limite du temps) et des personnes qui valide en permanance.  
Il y a des petits comme desactiver le bouton submit lorsqu'il à été cliqué,  
Page 1 => Page opération::opération terminée=>Page1   comme ça si le mec reload la page1 il ne reposte pas.
 
 
Sur une application que je suis en train de faire je me sert d'une sécurité que j'avais mis en place pour éviter le double post.
Dans chaque fichier de script en bas je place ceci  
$_SESSION['from']= $_SERVER['SCRIPT_NAME'];
je poste toujours sur un autre fichier et au debut de ces fichiers de reception des post il y à ceci

Ceci me permet de définir clairement d'ou provient le post et déviter les multiples validations

Un début de piste associé à une redirection et en plus une vérification
 
Juste comme ça, si un utilisateur est capable de poster des messages à 3s d'intervalle soi:
- il est très fort
- soit c'est un refresh, aaaaaaaah
- soit il raconte de la merde
 
En écartant le cas un peu probable,  les 2 autres cas c'est "Tu posteras plus tard ". Et c'est pas dur de savoir quand il a posté la dernière fois sans retourner une base de donnée
 

oui, en fait ce que j'ai mis c'est plutot pour éviter le brute force (sur un formulaire de login par exemple). Mais je ne sais pas si c'est vraiment efficace alors je poste pour avoir des avis
 
(et en même temps, ca évite de pouvoir faire un refresh du postage normalement)

Ne perdez pas de vue qu'une IP n'identifie pas de manière unéquivoque un utilisateur final. C'est con, hein ? Sans doute les solutions proposées fonctionneront dans 90% des cas si elles sont correctement implémentées, mais le risque est grand, surtout si le site est fréquenté, de bloquer abusivement une IP et un utilisateur "innocent".
 
Il n'est pas déraisonnable d'imaginer que plusieurs utilisateurs se connectent depuis une université ou une école, avec la même IP, parce qu'ils ont des goûts communs ou que l'adresse de ton site a fait le tour entre copains. Tu risques alors de bloquer, à l'extrême, une des deux personnes qui ont chacune posté un seul commentaire !
 
Ca n'a rien d'hypothétique : au boulot, il n'est pas rare que deux collègues trainent sur le même site - et que je te passe une URL par Messenger, mate-le-site pour voir.
 
A toi de voir s'il est acceptable de bloquer un ou plusieurs "inncocents" - pour moi, ça ne l'est pas : un blocage de ce type et c'est good-bye.
 
La combinaision IP + cookie n'est opérante que si TOUS les utilisateurs acceptent les cookies.
 
Une alternative peu coûteuse, aisément déjouable malheureusement mais qui garantit 'zero collateral damage' est de se baser uniquement sur un cookie (ou l'équivalent ré-écrit dans l'URL).
 
Pas de solution miracle je le crains.

Perso, mon forum ne fonctionne pas sans cookies, donc effectivement, suffit de créer un cookie qui dure 10 secondes (ou plus, à voir) et au moment de poster, vérifier, si il existe, houlà, trop pressé.

Salut et merci à tous,
 
vos contributions vont bcp m'aider.
Vu que je ne veux pas faire de trop grosses modifs, je vais partir sur la propal de Akn qui me semble simple et passe partout.
 
Si j'ai une idée ou un prob je vous tiendrais informé.
 
encore merci
a+

Et les limitations ? Tu en tiens compte ou tu t'assoies dessus ?
 
Parce que c'est facile de s'inspirer d'un code en 10 lignes qui donne l'illusion d'une solution, mais si c'est pour se créer autant de problèmes qu'on en résoud...

 
Ca m'a donné l'idée de base et c'est très bien.
J'ai dû l'adapter à ma sauce et surtout à l'architecture de mon site. Ca marche et ça me va. Ca me permet aussi de ne pas revoir l'ensemble de l'archi justement. Je n'ai pas le temps ni l'envie.
Conclusion, il a mieux à faire mais ça a un coût....que je ne peux m'offrir (pour l'instant du moins).

Explique les limitations.
Si il passe une variable en session, ça passe en cookies ou dans la session de l'utilisateur.
Je pige pas les limitations.

La combinaison IP+cookies n'est pas suffisante. Sauf peut-être à rendre les cookies obligatoires, et encore : un anti-flood aussi rudimentaire n'aura que l'effet d'un speed-bump pour ralentir le flooder lambda - ce qui n'est déjà pas si mal.
 
Un flood à peine robotisé, avec un curl, s'écrit en 3 lignes et permet de se jouer des cookies. Bien moins fréquent que le F5, j'en conviens.
 
Je ne vois nulle part de solution à la fois complète ET qui ne risque pas de bloquer des utilisateurs normaux.
 

Heuuuu ??? Bon, à ça, y'a rien grand chose à dire.  
 
Par pure curiosité, quelle solution as-tu choisi plus exactement ?

Ha oky.
Disons que je ne voyais pas de limitation car j'oblige mes forumeurs à accepter les cookies pour poster.

Tu es donc dans un cas assez favorable où le F5 ne passera pas, sans vraiment gêner les utilisateurs par ailleurs - la contrainte des cookies est très modeste et est pré-existente à ton anti-flood. Mais ne perdons pas de vue qu'elle n'est parfois pas acceptable.
 
Par contre, un simple bot passera, mais ça réduit déjà le risque de 90-99% sans doute.
 
     

pardon je m'incruste, il a dit qu'elle soluce il a choisie, celle de akn:
   1. if(time()-$_SESSION['lastpost']<30) die("flood" );
   2. else
   3. {
   4. requete sql;
   5. $_SESSION['lastpost']=time();
   6. }
je trouve aussi que c'est pas si mal comme soluce...

 
Sessions PHP : je chope le timestamp au post. Et si le gus fait F5, je le jette car en plus des données du formulaire, je teste s'il y a un timestamp dans la session et si il est trop récent (30 sec) je lui mets un message d'erreur. Sinon, ca repasse (la soluce de Akn en fait).
Par contre, tu me mets le doute sur le cas où qq'uns de mes users sont derrière un proxy en entreprise...
 
 

perso j'ai une table de flood qui autorise 3 posts consecutifs sur une periode de 10 minutes. Lors de la soumission d'un message je controle la presence d'un message identique durant les 30 dernieres secondes pour le meme utilisateur et meme sujet.

 
Oui mais il ne s'agit pas chez moi d'un forum donc ça n'est pas adapté. Enfin ça irait mais je n'ai pas envie de monter un tel truc pour si peu
Si c'était un forum, je procèderai de la même manière je pense.

Effectivement, je reponds à la question initiale.

 
Je pense que tu as pas mis le reste exprès.
PArce qu'il faut bien trimballer la valeur de ta variable submit APRES la 1ère soumission (valide par définition). Dc ca implique aussi de stocker ca ds une SESSION ou un cookie.
Dc l'intérêt est juste de ne pas repartir vers le serveur pour rien.
S'il a désactivé le JS alors là tu jettes en PHP.
 
Je n'ai pas fait l'effort de le jeter en JS

Franchement, quand je vois vos idées j'hallucine. Si vos scripts et fichiers étaient bien agencés vous n'auriez pas à gérer ce problème de façon bricolage. je pourrais  paraitre prétentieux mais j'ai indiqué la réponse plus haut mais comme je l'ai compris cela ferait modifirer vos fichierd ainsi qu'une autre façon d'organiser ces scripts et le fichiers. off.

Certains savent coder, d'autres savent écrire  

 
D'autres ne savent faire aucun des deux  

Exact !  

Oui mais je joue pas les chauds devant bernard pivot    

 
L'agencement de mon site est assez classique je pense même s'il faudrait que je fasse 2-3 modifs que je n'ai pas envie de faire là.
En gros :
Une page index.php :
- qui gère le login/les tentatives d'intrusion.
- qui contient l'interface graphique (bandeau, menus)
- qui pilote le membre en fction du paramètre ?page=xxxx. A chaque page, on include un fichier xxxx.php au coeur de la page index.
 
Prob : vu que j'ai déjà "écrit" dans la page AVANT de faire l'include, je ne peux plus faire de "header('location: ....php')" ! Mon problème est là.
Il faut dc que je corrige ça.
Là soluce que je pense faire est de déporter l'architecture graphique de mon site ds des fichiers PHP et je les includes dans chacunes de mes pages xxxxx.php.
De cette manière :
- rien n'est jamais écrit dans la sortie standard AVANT la validation du script : "header('location: ....php')" = OK !
- je n'aurais qu'à modifier 1-2 includes pour le graphisme : pas de régression à ce niveau.
- je ne casse pas le principe index.php?page=xxxx qui me ferait reprendre mes 50-60 pages et script ! l'enfer quoi.
 
Prob : pas le temps de faire ça maintenant d'où ma question sur une soluce simple pour l'antiflood.
 
Et puis l'idée de Akn s'apparente peut etre à du bricolage mais ca reste propre et assez simple dc ca me va.  

ha ouais donc tu as avancé et maintenant tu te retrouve pris au piege
Je pense que tu t'es retrouvé dans une situation trop avancé pour le modifier. Bon bref c'est déjà fait.  
Fait en sorte qu'il ne soit pas possible de reloader la meme page sans donner l'autorisation dans des condition précise. Tu stock le l'url du script en court en bas de la page. si a l'arrivé de la page elle est identique que celle de la session ou qu'elle n'a pas a venir de là  c'est qu'elle a été reloadé ou tentative de recule.  
A ce moment là a toi de décidé de ce que tu vas faire mais avec ça tu es obligé de corriger tout les fichier.
Si j'ai bien compris ton probleme

 
you bet
et j'ai saisi ton "truc" dans ton message plus haut.
Je ferais une migration quand j'aurais le temps. Ce site est pour le fun, rien de professionnel dc j'ai d'autres chats à fouter.
merci pour tes conseils