Bonsoir,
 
Excuser moi de vous deranger, mais j'ai besoin de votre aide et conseil pour une question :
- j'ai un systeme de points sur mon site : les membres obtiennent tant et tant de points en postant des presentation de jeu dans un formulaire : si le formulaire est ok on credite x points en plus à l'utilisateur.
--> Le seul hic c'est que si l'utilisateur fait F5 une fois arrivé sur le message de confirmation il obtient le nombre de points qu'il veut.
 
Comment arranger ce problème pour bloquer le rechargement ?
En bloquant au niveau du temps ?
 
 
Merci beaucoup d'avance.

tu peux, mais tu peux aussi faire une redirection serveur transparente (genre un header) qui rend impossible le renvoi du formulaire ... dans l'immédiat, pas d'autres idées.

Je te remercie de ta réponse NewsletTux.
Je ne vois pas trop comment on peut concevoir cela !?
 
Car au debut j'avais pensé faire à la phpBB : c'est à dire bloquer pendant 15 secondes ne pas avoir acces à la page par exemple mais bon ça ne resoud pas vraiment mon probleme.
 
Bonne nuit.

Le protocole HTTP 1.1 a un header spécialement fait pour cela : 303 See Other.
 
Donc au lieu d'afficher la page confirmation, on fait une redirection vers celle-ci via un 303, genre :

header('Location: http://tonsite/machin/succes.php', true, 303);

 
Donc déjà avec un simple F5 y'aura plus de données POST envoyée, il va juste rafraîchir la page de confirmation.
 
Maintenant ça l'empêche pas de faire "Précédent" et de réenvoyer le formulaire, donc faut un autre systus : token à usage unique dans le formulaire, validation par un humain, etc.

Merci FlorentG pour ta réponse rapide,
 
Merci pour ce code qui fonctionne a merveille. Mais comme tu le souligne bien, l'utilisateur peut revenir en arriere et faire valider à nouveau.
- il y a la possibilité de l'humain, mais je souhaite que mon systeme soit actif de suite, et que les presentations de jeu n'ont pas besoin d'etre validé (trop de boulot). Seulement si par la suite je m'apercoit qu'il y a des abus, là je peux voir (recuperant le log de tout : id_utilisateur, heure de l'envoi, pour quel id jeu, avec quelle adresse IP).
- Ensuite qu'est ce que le token ? (j'ai du mal a comprendre sur le site de php.net).
 
 
Merci encore

Salut !
 
Il te suffit de générer un "jeton" lorsque tu arrives sur ta page du formulaire.
Tu mets ce jeton en session et comme ça si la personne fait F5, le jeton qui sera à nouveau créé ne correspondra pas à celui qui est en session, donc son F5 ne fera rien de plus que rafraichir la page ;-)
 
Bon courage :-)

Bonjour à tous,
 
Vraiment du mal à comprendre : actuellement j'ai ma page de confirmation directement dans mon formulaire d'ajout (mais je ne suis pas sûr que ça soit différent ainsi).
 
Je vais voir toujours
 
 
Merci

je vais p-ê dire une bêtise, mais si on se base sur l'IP (donnée certes falsifiable), en un rafraichissement de page, on voir que c'est la même IP qui réenvoie ... il est très peu probable (ça dépend quel public on cible) que 2 personnes aient la même IP (sauf derrière un routeur) donc on peut considérer qu'une IP ne doit faire qu'un envoi ...

Les sessions n'ont plus car si les cookies sont désactivés on l'a dans l'os.

Merci beaucoup pour toute vos propositions.
 
Actuellement je fait comme cela :

 
 
Donc je vois plus ou moins avec ce que tu me dis Fred82 ; mais je ne vois pas où est la différence avec ce que je fais actuellement.
 
Merci encore enormement pour vos reponses.

faut stocker dans la base de donnée le fait que l'utllisateur a poster des informations. Ensuite, quand il en insère des nouvelles, faut vérifier qu'il en a pas déja postée aujourd'hui.

Oui c'est sûr (j'avais pensé faire suivant la date : par exemple que l'utilisateur doit attendre 30 secondes afin de reposter) ; mais personnellement il faut que j'autorise l'utilisateur a envoyé autant de fois un nouveau formulaire qu'il le veut.
 
Ou alors ; je comprend un peu mieux l'idée de fred82 et dj-julio : je me fabrique une variable composée de 10 chiffres aleatoires par exemple ; si ce chiffre se trouve deja dans la BDD alors il ne peut renvoyer son formulaire (donc faut que j'enregistre pour chacune de mes insertions ce chiffre aleatoire).
--> Qu'en pensez vous ? Pas trop de risque que le nombre à 10 chiffres retombent deux fois ? Pas de problème au niveau du cookie au moins ?
 
 
Merci

suffit de generer un GUID...

Bon je viens d'essayer en generant une cle longue avec tout les caracteres possibles et chiffres : ça me genere a chaque fois une nouvelle cle sur le meme formulaire : donc je ne peux garder une meme cle tout au long u meme formulaire.
 
La methode me semble pourtant la seule vraiment realisable mais ça ne fonctionne pas comme je fais (c'est à dire generer une cle et afficher la confirmation seulement si la cle generer n'est pas deja enregistrée dans la table).

Fred82 merci de m'avoir eclaire sur les sessions (meme si je connaisais deja plus ou moins).
Si la clé est générée a partir du moment que l'utilisateur se connecte a son compte (donc il créer un cookie avec la clé) ; et qu'il utilise la même clé tout au long de sa session ; il ne pourra pas poster 2 fois un formulaire d'ajout de jeu (chose que je veux autoriser).
 
Sinon je peux peut-être changer mon systeme de points.

"sauf derrière un routeur" ce qui veut dire :
- les abonnés AOL vu qu'AOL mets tous ses abonnés (ou au moins les abonnés RTC) derrière un petit nombre de routeur (d'autres FAI font surement pareil dans d'autres pays) pour limiter le nombre d'IP qu'ils sont obligé de réserver pour leurs abonnés
- ceux qui vont sur le net depuis leur boulot (généralement moins d'Ip que d'employés et assez souvent une seule par bâtiment)
- ceux qui habitent dans certains pays (ne pas oublier qu'il n'y a pas si longtemps wikipedia a bannis de ces serveurs un pays entié de l'europe de l'Est en bloquant une seule adresse IP)
 
Finalement, le "très peu probable" devient très vite "très probable" quand un site web prend de l'ampleur.
 
PS : A noter qu'avec AOL en RTC, l'adresse IP connus des serveurs web peut changer d'une demande de page à l'autre. Le serveur web peut donc croire que la demande vient de deux ordinateurs distincts si on se base sur l'adresse IP et ce même si l'utilisateur n'a fait qu'appuyer sur F5.
 
PS2 : Avec certains FAI et certains modem (ADSL, cable, fibre, ...) l'abonné peut demander un changement d'IP autant de fois (et surtout aussi souvent) qu'il en a envie. Un tel abonné qui connait la méthode qui a le bon modem et le bon FAI pourrait poster autant de fois qu'il veut si on se base sur l'adresse IP pour limiter le flood.

Une solution (peut-être pas la meilleure)
 
Il te faut  
  - un id unique par session pour ARRIVER dans le fomulaire.
  - un moyen de vérifier la validité de ton id
 
page précédent le form:

define('my_seed', 'ma_seed_introuvable');
$id_form = rand(10000);
$form_hash = md5(my_seed.$id_form);
 
header('location: form.php?id='.$id_form.'&h='.$form_hash);

form.php

define('my_seed', 'ma_seed_introuvable'); // le même bien sûr que la page précende. IRL, dans un include séparé
 
$id_form = isset($_REQUEST['id'] : $_REQUEST['id'] : false;
$hash = isset($_REQUEST['h'] : $_REQUEST['h'] : false;
 
if( $hash != md5( my_seed.$id_form ) ) die ('Ho ho ho, petit canaillou !');
 
if( deja_valide($id_form) ) die ('Vous avez déjà participé'); // ou un header location par exemple
 
?><form action="submit.php">
  <input type="hidden" name="id" value="<?=$id_form?>" />
  <input type="hidden" name="h" value="<?=$hash?>" />

 
submit.php

define('my_seed', 'ma_seed_introuvable'); // le même bien sûr que la page précende. IRL, dans un include séparé
 
$id_form = isset($_REQUEST['id'] : $_REQUEST['id'] : false;
$hash = isset($_REQUEST['h'] : $_REQUEST['h'] : false;
 
if( $hash != md5( my_seed.$id_form ) ) die ('Ho ho ho, petit canaillou !');
 
if( deja_valide($id_form) ) die ('Vous avez déjà participé'); // ou un header location par exemple
...

 
Cela implique que l'on a un moyen de vérifier que le formulaire $id_form a déjà été validé ou pas (par exemple en le stockant dans une base).
Cela implique aussi que le client ne puisse pas retourner sur la page précédent le formulaire pour regénérer un couple id/hash valide.
 
Par contre, ca marche meme avec des cookies désactivés et avec des formulaires créés à la main.
 
L'idée, comme tu peux le voir, c'est d'encoder une valeur publique (l'id_form) à l'aide d'une valeur privée (le seed). C'est le principe de base de la cryptographie moderne (cf dans google RSA, clé publique/clé privée, etc.

Ce n'est pas çà le problème !
Le problème c'est le cookie (par défaut PHPSESSID) qui identifie le client.

Ca ne veut strictement rien dire, les cookies côté serveur ça n'existe pas, les cookies sont toujours sur le client, et luc@s a parfaitement raison: si les cookies sont désactivées les sessions sautent (le client ne stockant pas le sessionid, il ne peut renvoyer celui-ci, le serveur ne peut donc pas retrouver la session et en recrée une à chaque fois), sauf à placer l'ID de session autre part (e.g. la majorité des serveurs d'application java foutent le sessionid dans l'URL quand les cookies ne sont pas dispos)

php aussi si c'est autorisé dans le php.ini .

oui mais on ne peut pas basculer automatiquement vers l'URL si les cookies sont désactivés. Me trompe-je

Si tu règles le php.ini pour que ça soit interdit alors il ne le mettra jamais dans l'URL. Sinon il basculera automatiquement du mode cookie au mode URL sans que tu n'ai à t'en préoccuper.
En fait, à l'ouverture d'une session, si rien n'est transmis par cookie alors le sessionid sera envoyé pour être stocké en cookie tout en étant rajouté à chaque URL présente dans la page.
 
Plus d'info dans la section sur les sessions et dans la page traitant de php.ini (lire les différentes directives correspondant aux sessions. Ca permet de comprendre assez bien ce qu'on peut ou non régler)
 
EDIT : A noter qu'on peut aussi autoriser les id de session par URL sans autoriser leur stockage dans les cookies. Mais côté sécurité, c'est vraiment pas le meilleur réglage.

ok, c'est bon à savoir