Session pour éviter de jouer plusieurs fois

par **charabia** » 17 juil. 2005, 00:27

Zut tu n'as pas tort pjl....ça va baisser le taux d'audience tout ça...lol

par **Cyrano** » 16 juil. 2005, 15:45

D'accord, je crois que je vais me pencher sur les IP alors
ca veut dire que si quelqu'un veut jouer à ton jeu en étant connecté au réseuau d'une école ou d'une fac, ce sera le seul à avoir accès à ton jeu à partir de cette école (ou fac).

Quand on est à l'école ou à la fac, c'est pas pour jouer en ligne

par **pjl** » 16 juil. 2005, 14:28

D'accord, je crois que je vais me pencher sur les IP alors

ca veut dire que si quelqu'un veut jouer à ton jeu en étant connecté au réseuau d'une école ou d'une fac, ce sera le seul à avoir accès à ton jeu à partir de cette école (ou fac).

par **charabia** » 16 juil. 2005, 13:49

Oui j'ai saisis le principe dans sa globalité

Je me penche dessus avec les IP en plus.

Merci à vous deux

par **rami** » 16 juil. 2005, 13:43

Comme tu t'en reds compte ca ne sert a rien de stocker l'id de la session dans ton cas.

Je pense qu'il faut que tu fasses un système d'authentification de tes utilisateurs comme te le disait Cyrano, avec un champ te permettant de savoir si l'utilisateur a déjà jouer.
Apres tu auras le schéma suivant:
- les utilisateurs arrivent sur ton site
- s'ils veulent jouer, ils tentent de s'identifier
- si l'identification réussi, tu regardes dans ta base si l'utilisateur connecté a déjà joué. Si oui, tu lui indique qu'il ne peut pas rejouer, si non, il joue. Et une fois qu'il a joué, tu stockes ds ta base le fait qu'il a joué.

- si l'identification échoue, page de refus, de login...

Tu saisis le principe?

par **charabia** » 16 juil. 2005, 13:41

D'accord, je crois que je vais me pencher sur les IP alors

par **Cyrano** » 16 juil. 2005, 13:40

Rien ne l'empèchera de vider son cache pour repartir à zéro après une partie.

Et puis à ce moment là, tu peux limiter le nombre de comptes: lors d'un enregistrement, tu peux forcer la validation par l'envoi d'un courriel comportant une adresse pour activer le compte. Il sera forcé de mettre une adresse de courriel et là, ça va tout de suite limiter le nombre à un compte par adresse de courriel. Tu ne pourras pas monter un système totalement étanche, donc quelqu'un qui a une vingtaine d'adresses pourra ouvrir autant de comptes... mais à la rigueur, tu pourrais dans ce cas récupérer l'IP au moment de l'enregistrement, lors d'une nouvelle tentative de la part de l'internaute, en vérifiant qu'il n'a pas la même IP qu'un autre compte existant, tu peux ou non ouvrir le compte. Tu pourrais même corser en générant toi-même les mots de passe sns possibilité de les modifier par l'internaute, avec vingt adresses et vingt comptes, ça fait 20 mots de passe différents, il va avoir des problemes pour tricher s'il n'est pas trop organisé.

par **charabia** » 16 juil. 2005, 13:39

C'est ce que j'ai fait rami, je stocke la session dans ma base de données grâce au champs caché :

Code : Tout sélectionner

<input type="Hidden" name="session_id" value="<?php echo session_id();?>">

Mon soucis vient du fait que la session en question n'est pas permanente. Elle change à chaque fois que la personne ferme son navigateur, du coup il suffit de fermer et de rouvrir son navigateur pour rejouer.
Tant que c'est ouvert, j'arrive bien à bloquer l'accès.

par **rami** » 16 juil. 2005, 13:35

Il faudra aussi un stockage de l'information permanent. C'est-à-dire qu'une foisque l'utilisateur ait joué, enregistré le fait qu'il ait joué dans une BD, un fichier txt...

Je ne suis pas bien sur de comprendre ton probleme, mais si tu ne veux pas qu'un utilisateur crée plusieurs comptes, ut peux bloquer au niveau de l'IP (bien que je ne sois pas fan de ce genre de restriction).

par **charabia** » 16 juil. 2005, 13:31

Cyrano, je vois la solution que tu m'as donné, mais j'ai un soucis dessus, c'est que la personne peut ouvrir des comptes multiples et jouer à tout va.

Là j'ai déjà bloqué l'accès au niveau du nom/pseudo. Si la personne remet le même nom, elle est bloquée et ne peut pas rejouer. Et donc pour éviter qu'elle ne change de nom je veux mettre en place ce système de session en plus.

par **Cyrano** » 16 juil. 2005, 13:29

Bon, il faut je crois remettre certains détails en place: là, on en est à mon avis pas encore au codage en PHP: il faut que tu détermine de façon logique la suite des évènements et que tu en distingues tous les éléments. Partant de là, tu peux isoler des points précis que tu devras traiter en manipulant des données.

Grosso-modo, il faut que tu crée un algorithme schématisant l'application.
Prends un papier et un crayon et note :

- l'internaute arrive sur le site;
- L'internaute se rend sur la page de jeu;
- l'internaute s'identifie:
- * l'internaute est reconnu : suite ...
- * l'internaute n'est pas reconnu : suite...
etc..

À partir de là, tu vas visualiser beaucoup plus facilement ce qu'il faut faire et tu sauras très bien par où commencer. Mais si tu programmes "à la perche", tu vas finir par vouloir balancer ton PC par la fenêtre.

par **charabia** » 16 juil. 2005, 13:26

Merci je vais voir ça de plus prêt.

par **rami** » 16 juil. 2005, 13:25

Je te conseille de lire la doc sur les sessions avant de commencer, pour que tu saisisses bien ce qu'est une session.

Je te fais un résumé:
Les sessions permettent d'avoir un variable globale ($_SESSION) visible dans tous tes scripts (à partir du moment que ton script commence par session_start()).

http://fr2.php.net/manual/fr/ref.session.php

par **charabia** » 16 juil. 2005, 13:19

Bé je veux bien utiliser les sessions pour ça. Il ne faut que la personne ne puisse jouer qu'une fois avant le nouveau jeu (identifié par un numéro de jeu).

Là pour le moment la personne soumet lors de l'envoi du jeu :
- la réponse
- son nom
- et la session que j'ai rajouté par le champs hidden.

Peux-tu m'aider pour la suite ? Parce que là je t'avoue que je ne sais pas trop par où commencer...

Merci !

par **Cyrano** » 16 juil. 2005, 13:19

La doc ?

Ceci dit, un cookie, ça s'efface, alors rien n'interdira à un futé de jouer, de vider son cache et de rejouer dix minutes plus tard et continuer toute la journée comme ça.

Solution: accès réservé aux membres et on doit s'identifier pour jouer. Lors de la connexion, tu modifie un champ selon que joueur à participé ce jour là ou pas encore. Par exemple, lors de l'identification, soit l'internaute a déjà joué et il ne peut plus rejouer, soit il n'a pas encore joué, la valeur du champ est à 0 par exemple et au moment de mettre à jour après son tour de jeu, tu mets ce champ à 1 pour la date en cours. Ou plus simple encore, tu crées une table historique de jeu: deux champs: la date et en clé étrangère l'id du joueur. Tu alimentes en ajoutant une ligne à chaque nouveau jeu.

Session pour éviter de jouer plusieurs fois

Répondre

Étendre la vue Revue du sujet : Session pour éviter de jouer plusieurs fois