Les submits répétés

[Sarc]

Bonjour à tous,

Sur mon site pitim€nde, les joueurs s'évertuent et s'acharnent à trouver des bugs dans le moteur de jeu pour devenir meilleurs que les autres... C'est marrant en un sens, mais le jeu est vite pourri par des tricheries en tout genre.

J'en ai une particulièrement qui m'énerve :

Quand on appuie plusieurs fois sur le Submit d'un formulaire avant que la page d'après ne s'affiche, le traitement PHP se fait plusieurs fois, et parfois sans même finir le traitement de la fois d'avant...

Par exemple, essayez sur un forum non protégé d'écrire un message et d'appuyer 10 fois sur "Envoyer" avant même que la page ne soit affichée. Avec un peu de "chance", vous aurez 10 messages affichés sur le sujet.

Sauf que moi, ça peut causer des dégâts irréversibles dans le moteur de jeu, et pourrir complètement la partie. Par exemple, les membres pouvaient acheter 100 objets alors qu'il n'y en avait seulement 4-5 en stock...

Je ne comprends pas pourquoi le traitement PHP ne finit pas avant de recommencer ?

Comment puis-je faire pour éviter qu'un traitement PHP d'une page pour un membre ne commence avant que tout ce qu'il a demandé ne soit fini auparavant ?

J'ai bien tenté de "bloquer" le bouton Submit après un clic, mais il suffit de désactiver le Javascript pour contourner ça.

Si vous avez connu des problèmes à cause de ça, et que vous avez des idées pour activer une protection sur l'ensemble de mes pages, je serai bien content...

Merci d'avance !

[Dudu]

Salut

Par exemple, essayez sur un forum non protégé d'écrire un message et d'appuyer 10 fois sur "Envoyer" avant même que la page ne soit affichée. Avec un peu de "chance", vous aurez 10 messages affichés sur le sujet.

Pas sur le Hub car il y a un contrôle de flood: sur le principe c'est ce qu'il te faudrait.

Empêcher le bouton submit de marcher normalement, tu n'y arriveras pas. C'est donc après qu'il faut vérifier le nombre de secondes entre deux actions.

[Sarc]

Salut Dudu

Je ne sais pas du tout comment est codé un contrôleur de flood, en réalité... Mais si c'est en regardant dans la base le time de la dernière action effectuée, je ne peux pas faire ça sur mon site, parce que les actions ne sont pas forcément toutes sauvegardées et répertoriées...

Avec un cookie qui contient le time, et qui empêche deux actions en moins de 2 secondes ? Ca laisserait au moins le temps au traitement PHP de finir...

Si tu connais les possibilités techniques de faire le contrôleur de flood efficacement, tiens moi au courant

Merci

[Mikiman]

Bonjour,

Le système est d'enregistrer le temps du dernier envoie par cet utilisateur, soustraire le time actuel par celui du dernier envoi pour récupérer le nombre de secondes écoulées entre l'envoi précédent et celui voulu actuellement.

Il faudrait éviter de passer par les cookies, ils peuvent être bloqués.

Cordialement,

Mikiman

[Sarc]

Si le cookie est bloqué, l'utilisateur ne peut de toute manière pas être logué sur le site, donc ne peut pas jouer au jeu... Donc les cookies ne peuvent pas vraiment être bloqués. Je trouve ça mieux que de faire les requêtes à chaque fois dans la BDD.

C'est en tout cas ce que je pensais... Après, je dois faire des tests de durée pour que tout marche convenablement

[Leonick]

ce que j'utilis : une variable de session

if (!isset($_SESSION['envoi_message']) || ($_SESSION['envoi_message']+60<time()))
{.../
	 $_SESSION['envoi_message']=time();
/...
}

[maximettb]

Ou alors un simple système de verrou en session, qui se met à 1 en début de page et revient à 0 à la fin. Après, l'idéal serait d'avoir des méthodes synchronisées comme en java, mais je ne pense pas que ce soit possible en PHP...

[Salesforce]

La remise à zero en fin de page est très délicate, car elle peut ne pas survenir, s'il y a une interruption de la connection avant l'achèvement des traitements par exemple (l'exécution php s'arrête en cas de rupture de connexion, par défaut)