Les sessions (sécurité, utilité, optimisation)

[Anthor]

La session ne reste pas... Ce n'est pas fait pour stocker, c'est uniquement fait pour transposer une variable, ou un objet d'une page à une autre.

Tu fais quoi qd le joueur laisse sa session expirer, tu lui redonnes 6 points d'action ?
Ce n'est pas fait non plus pour bannir un utilisateur, vous faites peur quand même avec vos solutions a la mort moi le noeud...

[Seren]

J'ai peut être une mauvaise vision des choses, mais pour moi, il faut conserver en session uniquement des "constantes". C'est à dire des variables qui sont constantes ou qui varient peu dans le temps : l'id de l'utilisater, son nom, éventuellement quelques caractéristiques "fixes".

Sortie de là on a des risques de désynchronisation, par exemple un personnage est censé être mort, mais comme en session il a toujours des données non rafraîchies, il peut encore se déplacer car le système le voit vivant de son point de vue.

Il ne faut surtout pas stocker une variable qui pourrait être modifier par une action d'un autre utilisateur.

[rygnes]

Tu n'as pas une vision assez large surtout.
En prenant l'exemple d'un chat tout bête et d'une session X comprenant notamment la variable de session 'onLine' qui vaut true si l'internaute est connecté, false sinon.

$_SESSION['online'] est initialisée à false à chaque connexion.
True est affecté à cette variable lorsque connexion au chat.

A chaque envoi de message,
|test sur $_SESSION['online']
|si true alors envoi message.
|si false alors refus d'envoi.

Si tu avais dû vérifier la connexion en lisant un fichier texte ou un champ base de donnée, le système aurait été plus long et peu perspicace.

Ce n'est qu'un exemple naïf parce que je n'en ai pas trouvé de mieux dans l'instant, mais si tu ne comprends pas ce que j'ai voulu dire, je tâcherais de trouver une illustration plus convaincante.

[keke]

Nambew, tu joues avec deux navigateurs différents sur le même jeu ?
Parce que si c'est le même navigateur, il s'agit de la même session.

2 navigateurs FireFox, ça marche très bien. J'ai 2 sessions différentes (je viens de faire le test.) Il suffit de configurer 2 profils différents ...

En mon sens, les variables de session ne sont pas des données fiables. Elles peuvent être utilisées que dans des cas précis :
- système de connexion
- formulaire en plusieurs pages (même si on peut les éviter)
- pour stocker des constantes propre au joueur. (le nom du joueur, le nom de sa ville principale, ...)
- pour stocker des id de tables qui sont pratiquement invariants durant la connexion de l'utilisateur. A utiliser dans l'idée d'optimiser ses requêtes.

Dans les autres cas, ne pas utiliser des variables de Session... (l'équipement => pas en session, le nombre de pièces d'or => pas en session, le nombre de soldat dans vos armées => pas en session, etc...)

Kéké
PS : si vous voulez déroger à la règle, je vous encourage à bien vous renseigner sur les sessions. Des bugs bizarres pourraient surgir ^^
PS : Chaque projet étant unique, il est bien difficile de donner une réponse globale. Principalement, si vous avez un système dans votre jeu qui vous offre un bonus toutes les X temps (une usine qui produit des soldats, un village qui rapporte des Glod, une potion qui rapporte des Pdv tous les X minutes, ... ), ces variables doivent être centralisées par un système unique ... en l'occurrence la BDD.
PS : j'ai pas compris le système de Tchat ...

$_SESSION['online'] est initialisée à false à chaque connexion.

[rygnes]

C'est noté pour Firefox.
Un autre exemple...

Un joueur se connecte, le jeu comporte des personnages qui peuvent faire différentes actions prenant chacune un temps précis.

Code PHP :

<?php 

//Nouvelle connexion



session_start();



//Initialisation 



//$requete['ActiviteEnCoours'] vaut TRUE ou FALSE

$_SESSION['Activite'] = $requete['ActiviteEnCours'];



//$requete['ActiviteEnCoursTimeStamp'] vaut n tel que 0 <= n <= Time()

$_SESSION['FinActiviteTimeStamp'] = $requete['ActiviteEnCoursTimeStamp'];



//Fin nouvelle connexion





//Dans chaque script relatif aux activités du personnage



function FinDActivite(){

         

        $_SESSION['Activite'] = FALSE;

        //Traitement liée à l'activité en question, enregistrement en BDD

        // des informations nécessaires (Activité (=Rien) et le résultat de l'activité);        

        ...

}



function DebutDActivite($ChoixActivite){



        $_SESSION['Activite'] = TRUE;

        $_SESSION['FinActiviteTimeStamp'] = time()

        + $requete['DuréeNécessairePourAccomplirAction']['ChoixActivite'];

        //Enregistrement dans la BDD des informations 

        //nécessaires (Activité et TimeStamp de fin notamment).

        //Autre traitement.

        ...

}



//A chaque fois qu'un personnage veut faire une action



if($_SESSION['FinActiviteTimeStamp'] != 0

    && $_SESSION['FinActiviteTimeStamp'] < time()){



      FinDActivite();

}



if(!$_SESSION['Activite']){ 



     DebutActivite($choixActivite);

} 

[Holy]

Il ne faut surtout pas stocker une variable qui pourrait être modifier par une action d'un autre utilisateur.

La session ne reste pas... Ce n'est pas fait pour stocker, c'est uniquement fait pour transposer une variable, ou un objet d'une page à une autre.

Tu fais quoi qd le joueur laisse sa session expirer, tu lui redonnes 6 points d'action ?
Ce n'est pas fait non plus pour bannir un utilisateur, vous faites peur quand même avec vos solutions a la mort moi le noeud...

Tout ça est stocké en base de données ^^

J'ai du mal expliquer le principe du cache et des mises à jours de session.

En gros:
J'ai un bête système qui permet de bannir un joueur. Ça modifie mon champ SQL "ban" dans ma table player_tbl. Ça crée un fichier qui indique au joueur banni qu'il doit rafraichir sa session. En rafraichissant sa session, $_SESSION['ban'] passe de 0 à 1 par exemple.

J'utilise ce système à grande échelle. Dés qu'une donnée d'un joueur est modifiée par un utilisateur autre que lui, le système provoque le rafraichissement de la session du joueur (avant toute action dans la page). Ce qui fait que les données de la session sont toujours fidèles à celles qui se trouvent dans la base de données. L'avantage étant que je ne dois pas faire de vérification sql.

Personnellement, je considère ces données comme fiables.

Ps: Le message de Keke était super intéressant, et j'avoue que son premier PS m'a fait sourire! C'est justement de traquer les bugs et les fixer qui est le plus marrant et le plus enrichissant :p (le coup de la double connexion)

[keke]

Rygnes > j'ai peur de pas comprendre. Tu cherches à faire un système met en variable de session le fait qu'un joueur fait une quelconque activité et doit donc refuser toute autre activité ...
En plus d'être très lourd à l'usage et à la programmation ... je pense pas que ça résolve le problème. L'information doit être centralisée.
J'ai beau relire ton message et le code fourni ... je comprends pas la question ^^. Je vais essayer d'y répondre.

Je pars de l'hypothèse que j'ai compris le problème tel que ré-écrit plus haut et je vais montrer un contre exemple.
J'ouvre 2 navigateurs indépendants. Appellons les IE et FF.
Je me connecte à ton jeu avec IE : Ma variable de session activité est à False, je ne bosse pas.
Je me connecte à ton jeu avec FF maintenant : ma variable de session activité est à False, je ne bosse pas.
Avec IE, je quémande un travail : je bosse. Ma variable de session IE est donc maintenant à True.
Je rafraichis ma page avec FF ... et là comme ma variable de session est à False ... je peux continuer à demander du travail.
=> Anomalie ...

Typiquement, l'information "je travaille" doit être en base de donnée ! tu dois vérifier avant chaque affichage de proposition de job si ton personnage travaille ou non (et donc s'il peut accepter du boulot ou pas). Tu dois faire la même vérification après que le joueur ai cliqué sur le bouton 'Postuler'.

Je veux pas balancer ^^, mais il me semble que Sephi-chan a fait de très belles réponses à ce sujet sur ce même forum !

Kéké qui n'arrive pas à lire ton code.
PS : je prends toujours 2 plombes à répondre aux messages, j'ai pas vu le message de Holy. Etant donné qu'il est mal vu de faire des doubles posts, j'édite celui là ...
Holy >

J'ai un bête système qui permet de bannir un joueur. Ça modifie mon champ SQL "ban" dans ma table player_tbl. Ça crée un fichier qui indique au joueur banni qu'il doit rafraichir sa session. En rafraichissant sa session, $_SESSION['ban'] passe de 0 à 1 par exemple.

J'utilise ce système à grande échelle. Dés qu'une donnée d'un joueur est modifiée par un utilisateur autre que lui, le système provoque le rafraichissement de la session du joueur (avant toute action dans la page). Ce qui fait que les données de la session sont toujours fidèles à celles qui se trouvent dans la base de données. L'avantage étant que je ne dois pas faire de vérification sql.

Personnellement, je considère ces données comme fiables.

Et moi je suis persuadé que ton système n'est pas le plus efficace. Sans offense bien évidement car j'ai commencé comme toi et que sans m'en apercevoir un type avait réussi à "filouter" ma BDD ... Dans mon bonheur, ce "filou" a eu la maladresse de pas faire gaffe ... il s'était donné 5000 pièces d'or, mais avait perdu 800000 tours. Un hasard qui m'a permis de localiser l'individu, lui souffler dans les bronches comme il se doit et ça n'a pas débordé ... (ha oui, sur Magdales, 1 Pièce d'or représente une bonne semaine de combat pour un vétéran ...).
Alors pourquoi dis-je que ton système n'est pas le plus efficace ? Pourquoi a ton avis avons-nous inventé les bases de donnée ? Il serait prétentieux de donner une réponse exhaustive à ces deux questions, mais : la gestion de donnée de données concurrentielles et la facilitée de mise à jour seraient 2 pistes de réflexion.
En gros, ça prend pas tellement plus de temps de faire une requête SQL à ta base de donnée, que de tester la présence ou l'absence d'un fichier correctement formaté. Par contre, la gestion des droits de fichiers varient selon les OS ... Si tu veux débannir un joueur, auras-tu les droits de suppression du fichier dans ton nouvel hébergeur ?
Aujourd'hui, tu utilises ton système de fichier pour le bannissement. Demain, tu en auras besoins pour d'autres variables ... vas tu faire un système compliqué de fichier à chaque fois ?
La technique que tu emploies était très utilisée avant ... Ton fichier s'appelle un "Flag" si tu veux faire des recherche Google sur cette technique.

Sache qu'il existe une autre technique qui permet de modifier directement la Session d'un autre joueur ... Je ne l'utilise pas, mais ce n'est pas le cas de certains créateur de jeu sur ce forum... En mon sens cette autre technique doit être bien maitrisée sinon c'est le moyen le plus directe d'aller à la catastrophe ...

kéké (bis)

[phenix]

Perso, j'ai en session, l'id du joueur, son pseudo, le serveur sur lequel il joue et sont IP. C'est tout, le reste sort de la base de donnée. Cela permet de faire une sorte de "realtime" car au moment ou un joueur ce connect, il peut arrivé qu'un autre l'attaque par exemple. Cela est directement mit a jour sur la page.

En y réfléchissant bien, on ne peux pas faire beaucoup confiance au session, car on est tout simplement pas sur quelle soit à jours.

[Holy]

Et moi je suis persuadé que ton système n'est pas le plus efficace. Sans offense bien évidement car j'ai commencé comme toi et que sans m'en apercevoir un type avait réussi à "filouter" ma BDD ... Dans mon bonheur, ce "filou" a eu la maladresse de pas faire gaffe ... il s'était donné 5000 pièces d'or, mais avait perdu 800000 tours. Un hasard qui m'a permis de localiser l'individu, lui souffler dans les bronches comme il se doit et ça n'a pas débordé ... (ha oui, sur Magdales, 1 Pièce d'or représente une bonne semaine de combat pour un vétéran ...).
Alors pourquoi dis-je que ton système n'est pas le plus efficace ? Pourquoi a ton avis avons-nous inventé les bases de donnée ? Il serait prétentieux de donner une réponse exhaustive à ces deux questions, mais : la gestion de donnée de données concurrentielles et la facilitée de mise à jour seraient 2 pistes de réflexion.
En gros, ça prend pas tellement plus de temps de faire une requête SQL à ta base de donnée, que de tester la présence ou l'absence d'un fichier correctement formaté. Par contre, la gestion des droits de fichiers varient selon les OS ... Si tu veux débannir un joueur, auras-tu les droits de suppression du fichier dans ton nouvel hébergeur ?
Aujourd'hui, tu utilises ton système de fichier pour le bannissement. Demain, tu en auras besoins pour d'autres variables ... vas tu faire un système compliqué de fichier à chaque fois ?
La technique que tu emploies était très utilisée avant ... Ton fichier s'appelle un "Flag" si tu veux faire des recherche Google sur cette technique.

Sache qu'il existe une autre technique qui permet de modifier directement la Session d'un autre joueur ... Je ne l'utilise pas, mais ce n'est pas le cas de certains créateur de jeu sur ce forum... En mon sens cette autre technique doit être bien maitrisée sinon c'est le moyen le plus directe d'aller à la catastrophe ...

kéké (bis)

Je pense que si le système est bien fait, il n'est pas spécialement compliqué. Je n'utilise pas un flag pour chaque type d'événements (bannissement, débannissement, etc.), mais un flag général qui déclenche une sorte de "nouveau login" (de la même façon qu'on actualise les données de session lorsque "minuit" sonne et que par exemple les points d'action des joueurs augmente de 5).

A bien y réfléchir, la modification de données par un utilisateur étranger est quand même relativement ponctuelle. C'est l'admin qui modifie tel ou tel champ, le modo qui bannit un joueur des forums, un chef d'alliance qui modifie ton "grade".

Pour les évènements plus spécifiques, à priori, dans un jeu php, aussi complexe soit-il, il n'y en a pas 50.

En ce qui concerne l'OS du serveur et ses spécifications, c'est comme pour tout, il faut avoir une solution adaptée à ses besoins Ça vaut pour les droits sur les fichiers comme pour les bases de données et les versions de php.

Je reste convaincu qu'en étant bien organisé, qu'en sécurisant correctement l'accès aux données, on peut facilement utiliser des données de session de manière fiable.

Edition: Et pour sûr, je ne pense pas que mon système soit le plus efficace ^^ C'est une proposition parmi tant d'autres

[Roworll]

Pour la modification directe des informations de session d'un autre joueur, j'avais posté un bout de code ici

Pour éviter les multi-sessions, j'ai un truc de ce genre à la connexion

Code PHP :

<?php 

//Sauvegarde du session_id en cours

$oldSession=session_id();

//Fermeture de la session actuelle

session_write_close();

// Le session ID étant enregistré en BDD à chaque connexion

// je vais recharger l'ancienne session enregistrée dans les informations du joueur

// grace à son ID si elle est encore active

if(!is_null($lnL['login_session']) && session_id($lnL['login_session'])!=''){

    //Démarrage de la dernière session enregistrée

    session_start();

    //Suppression de l'ancienne session

    session_destroy();

    //Fermeture & Sauvegarde

    session_write_close();

    //Je recharge ma session originale

    session_id($oldSession);

}

//Maj des informations de session dans la table joueur

$db->query('UPDATE player_login SET login_session=\''.session_id().'\' WHERE login_id=\''.$_SESSION['Player_Id'].'\'');