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

[keke]

Holy > Ok ^^.
C'est une proposition comme une autre avec son avantage et Ses inconvénients ... J'indique juste qu'il y a une solution moins compliquée et plus fiable.
Dans les inconvénients, si tu veux faire un cadeau à tous tes joueurs (donner de l'or par exemple), tu vas lutter à moins d'avoir la fonction adéquate. Avec une base de donnée, tu fais un "update ... " et c'est fini ^^.
Ta méthode te bride au niveau des interactions joueurs (pour les prochaines évolutions de ton jeu ^^, qui est très joli !).
La compatibilité des OS est une autre limite (dans ton cas, de toutes les manières tu va vouloir vérifier que ta base fonctionne ^^. Avec ta méthode tu feras double vérification.)
Et tous les autres inconvénients...

Les logiciels d'antan qui utilisaient des flags n'avaient pas de bdd du tout. Ce système de flag est donc adapté car aucun effort n'était nécessaire pour s'approcher d'une BDD. (un logiciel commercial comme bien d'autre qui utilise le système de flag : Tuxedo)
Par contre, je reconnais que c'est une bonne méthode pour apprendre à gérer des fichiers ^^. En mon sens, l'intérêt se limite là.

Mon avis n'a pas pour but de te dire : "C'est nase ce que tu fais". Juste pour mettre en garde les autres créateurs de la limite de cette méthode et pour leur éviter un long travail de remis en état par la suite de leur projet ^^.

Bonne journée !
Kéké
Roworll ^^ > ca fait un bail. J'avais même oublié ton pseudo sinon j'aurais cité tes sources. (me souvenais juste de ton avatar ^^)
Toi qui utilise le système de session. Peux-tu nous parler des limites d'un tel système ? Tant au niveau maintenance, fiabilité des données ... et expliquer les travers à éviter.

[rygnes]

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.

Effectivement, tu n'as pas compris mais c'est de ma faute.
Tu cherches l'intérêt de ce système là où il n'est pas.
Il y a une mise à jour BDD, je n'ai pas confiance dans les sessions, il ne s'agit là que d'un raccourci (nous parlions d'optimisation).

Je reprends ta démarche.

Je me connecte 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 (mise à jour de la BDD). Ma variable de session IE est donc maintenant à True.
Je rafraichis ma page avec FF ... et là comme ma variable de session est à False le script va interroger la BDD (ce qu'il n'aurait pas fait si la variable de session était à TRUE, il s'agit d'une petite économie de ressource) ...

C'est plus clair ?

Roworll, pourquoi éviter les multi-sessions ?
Tu te bases dans un cadre où tu stockes des données sensibles ?

[Zamentur]

Ouai je met vraiment en garde sur cette méthode! (accés à une session etrangére via session_id)
Car elle pourrait éventuellement permetre un vol de session!
Pour l'éviter, il faut bien s'assurer de faire le session_id avant d'envoyer quelques choses au navigateur!

Et même là je ne suis pas sur qu'un seul cookie soit envoyé(la doc n'est pas clair à ce sujet) il se peut que 2 cookie soit envoyé via http!
Autrement dit un bon pirate pourrait voler la session modifié.

En tout cas si on utilise session_id aprés avfoir envoyer l'entete http, c'est sur il y a une faille.

Autrement dit, gaffe, je pensais aussi faire un super système permetant d'accéder au donnée d'autrui, pour l'instant j'ai mis en pose parce que j'ai pas encore fait les test décris au dessus!

NB: si quelqu'un a déjà vérifié, je suis preneur! Si vous utiliser la méthode sans avoir fait de vérif, vous avez peut etre un trou de sécurité important!(surtout si la session étrangére modifié est celle d'un utilisateur privilégié (comme un admin, modo etc...) par exemple pour prévenir directement la personne que quelques chose à eu lieu)

Il serait plus sur de simuler les fonctions session en allant chercher directement les fichiers, sans oublier d'appeler flock() car là aussi il y a des failles de sécurité quand on modifie ou lie des fichiers sans appeler flock()...

IMPORTANT
Enfin un trucs concernant les sessions, il est primordial lors de l'appel à session_start d'utiliser session_regenerate_id afin d'eviter qu'un utilisateur ne se fasse imposer son numero de session.
Ce qui serait l'équivalent d'un vol de' session, et malheureusement beaucoup d'application sont vulnérable à cette faille!

Car le plus souvent le pirate connait l'id de session car c'est lui qui l'a imposé, en envoyant un lien à quelqu'un avec un PHPSESSID définit en GET

Donc méfiance, méfiance.

En dehors de çà je crois que les données ou plutot l'utilisateur affilié au donnée est fiable... (enfin presque si on oublie les CSRF)

EDIT: pour ceux intérrésser par toutes les questions de sécurité, j'ai trouvé ce site http://www.securite-info.org/ c'est le seul à parler bien de certaine faille que j'ai pu rencontrer. Cependant il n'y a rien sur le vol de session! D'ailleur je ne connaissais pas la faille nullbyte tel que décris dans un des tuto.

[keke]

Effectivement, tu n'as pas compris mais c'est de ma faute.
Tu cherches l'intérêt de ce système là où il n'est pas.
Il y a une mise à jour BDD, je n'ai pas confiance dans les sessions, il ne s'agit là que d'un raccourci (nous parlions d'optimisation).

Je reprends ta démarche.

Je me connecte 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 (mise à jour de la BDD). Ma variable de session IE est donc maintenant à True.
Je rafraichis ma page avec FF ... et là comme ma variable de session est à False le script va interroger la BDD (ce qu'il n'aurait pas fait si la variable de session était à TRUE, il s'agit d'une petite économie de ressource) ...

C'est plus clair ?

C'est effectivement plus clair ... mais je sens toujours l'anomalie :
Je sors un autre contre exemple (je voulais te l'envoyer via MP, mais je ne peux pas ^^ Faut réactiver quelque chose dans ton profil.)
Je bosse :
J'ouvre IE : variable à True
j'ouvre FF : variable à true.
Avec IE, j'abandonne mon job : variable à False maintenant
Avec FF ... on m'indiquera que je suis encore en train de bucher.

Ps : la méthode roworII résoudrait ce problème ... mais, moi qui utilise souvent le multi-fenêtrage ... sans intention de triche, j'aurais bien du mal. Je ne sais pas à quel point les gens utilisent du multi-fenêtrage. RoworII, as-tu des stats ?

Comme tu vois, ton système ne semble pas fonctionner ... Crois moi ou non, mais j'ai tourné et retourné ce problème dans tous les sens ... j'ai conclu qu'il fallait centraliser un certain nombre d'informations ... ta variable de Job en fait parti. Ma conclusion : contrôle avant clic, contrôle après clic ... C'est indispensable (je pense que Sephi est du même avis que moi)

Kéké

[Holy]

Kéké, le multi-fenêtrage n'est pas obligatoirement à faire dans "deux navigateurs" différents ^^

Personnellement j'utilise un système similaire à celui de roworII, même si les modalités sont différentes. Et rien ne m'empêche d'ouvrir deux fenêtres firefox ou IE. Par contre oui, impossible d'avoir deux sessions sur le même joueur.

Et à propos des fonctions généralistes, du genre donner or +5000. Il me suffit de faire un update et de créer un fichier général (et non plus spécifique pour chaque joueur (encore que je puisse créer "autant de flags que de joueurs" lol)) qui provoque la mise à jour des sessions des joueurs. Ça me fait deux types de cas et deux vérifications de fichier à faire pour préserver la cohérence. Et je ne trouve pas que les interactions pâtissent de ce système. De nouveau, ça ne change rien par rapport à une utilisation normale de la BDD, sauf que je crée un système de cache des modifications plutôt que de vérifier sur chaque page. C'est une sorte de système de cache en quelque sorte. Et à l'instar de celui-ci, il faut qu'il soit bien pensé pour qu'il soit efficace.

Ça dépend fortement de la structure du jeu évidemment.

[rygnes]

En fait si, cela fonctionne , il faut juste intégrer le prérequis "X ne peut pas abandonner une action en cours" (avec cela, tout devrait y être).
Et c'est là justement que c'est propre à chaque script.
Ce n'est absolument pas une mise en oeuvre générique.
Tout cela pour dire qu'il y a toujours plusieurs possibilités et que toutes ne sont pas toujours adaptables suivant ce que l'on souhaite faire.

Crois moi ou non, mais j'ai tourné et retourné ce problème dans tous les sens ... j'ai conclu qu'il fallait centraliser un certain nombre d'informations ... ta variable de Job en fait parti. Ma conclusion : contrôle avant clic, contrôle après clic ... C'est indispensable (je pense que Sephi est du même avis que moi)

Je te crois de manière générale, mais ce que je t'ai donné n'entre justement pas dans un cadre général. Ce serait plutôt un cas particulier.
Je ne facilite pas les choses en ne donnant qu'un brouillon de code :/.

[keke]

Rygnes > Coucou ^^,
Peut-on continuer la discussion par MP ? On indiquera la conclusion de nos arguments sur ce sujet. (ton profil est configuré pour ne pas recevoir de message privé.)

En gros, mes arguments tiennent aussi lorsque l'action en cours se finit naturellement ... mais tu appuies mon argument indiquant que ta méthode devient très restrictive au niveau des fonctionnalités. Voir carrément bloquante.

Je suis suffisamment nuancé pour savoir qu'il existe souvent plusieurs méthodes de résolution d'un problème, mais je suis aussi lucide pour reconnaitre les avantages et les inconvénients de ces méthodes. Ton cas n'a rien de particulier. J'ai un système de métier sur Magdales qui fonctionne de la même manière : à 19h les joueurs quittent leurs emplois mais ils peuvent le faire aussi avant en abandonnant ainsi leur paye.

Si tu as mis en place un bout de code disponible sur ton site (http://www.rpg-eruptio.com/) je pourrais essayer de te montrer le problème.

Contrairement à ce que tu sembles croire, ton cas est archi-généralisable : Je ne vois pas en quoi il n'est pas adaptable ... a moins de ne pas vouloir modifier son code.

Mon but encore une fois n'est pas de te casser, mais d'arriver à montrer aux autres (surtout les novices) les erreurs qui peuvent arriver. Si je parviens à te convaincre, je pense que cette discussion pourra servir de référence et qu'on n'aura plus à y revenir ^^ (voir qu'on fasse un tuto avec les 2 méthodes en expliquant les travers de l'un et les avantages de l'autre ;-) ).

Kéké
PS : Holy > MP
PS : Orditeck > je n'ai pas rencontré une seule fois le bug qui tronquait mes messages en 2 à chaque fois que je les éditais. C'est peut-être lié à la nouvelle version du forum ?

[rygnes]

Oups, mauvais réglage...
Nous pouvons continuer par MP...
Et ne t'inquiète, il n'y a rien de cassant là dedans, la discussion étant le principal intérêt d'un forum.
C'est reparti !

[Roworll]

Toi qui utilise le système de session. Peux-tu nous parler des limites d'un tel système ? Tant au niveau maintenance, fiabilité des données ... et expliquer les travers à éviter.

Les sessions sont à la base de simples fichiers contenant une version sérialisée de la variable $_SESSION. L'intérêt d'écrire directement dans la session d'un autre joueur est d'envoyer des informations sans utiliser de bases de données.
Prenons l'exemple de l'envoi d'un message.
Le joueur A envoie un message au joueur B.
Dans la plupart des cas, un champ "message en attente" est renseigné sur l'enregistrement correspondant au joueur. Pour avoir une réactivité optimale et prévenir rapidement le joueur B de l'arrivée d'un message, cette valeur doit être vérifiée à chaque fois changement/actualisation de page.
Cela implique de nombreux accès inutiles en base de données pour vérifier à chaque fois s'il existe un message en attente.

Passer par les variables de session permet de s'affranchir de la base de données. Les variables de session étant chargées à chaque page (du moins lorsque on utilise les sessions), les informations concernant un message en attente le sont aussi et un simple isset() permet de le détecter. On évite donc de nombreux accés en BDD.

Les limites du système est que cela reste ce que l'on pourrait appeler du J2J (Joueur vers joueur). Vouloir mettre à jour les informations de session de tout le monde ne ressemblerait pas a grand chose. Par contre, pour prévenir une personne (ou au pire un groupe de personnes) avec une session active (donc connectée sur le site) c'est impeccable et une excellente alternative au memcache ou APC que Studio Gamboo affectionne tant (certainement à juste titre) mais qui malheureusement est inutilisable sur bon nombre de serveurs mutualisés.

Niveau sécurité, les fichiers de sessions sont gérés par le système d'exploitation / serveur Web. Je suis donc assez peu inquiet de ce coté là.

Roworll, pourquoi éviter les multi-sessions ?
Tu te bases dans un cadre où tu stockes des données sensibles ?

Ce système me permet surtout d'éviter des sessions restant la patte en l'air, des sessions fantômes qui trainent alors qu'elles n'ont plus lieu d'être. Sur mon serveur de test, en windows, elles sont légion à rester dans le dossier de gestion des sessions alors qu'elles sont supposée n'avoir qu'une durée de vie limitée.

Quand aux données sensibles, je ne les mets jamais en session mais toujours en base de données. Si par ce système j'évite le multi session, je peux combattre le multi fenêtrage / l'utilisation d'onglets et les dérives que cela pourrait impliquer en cas de trop grande confiance aux données sensibles placées en variable de session. Rien ne remplace un bon InnoDB avec les transactions pour garantir la cohérence des données.

[Sephi-Chan]

Rien ne remplace un bon InnoDB avec les transactions pour garantir la cohérence des données.

Un PostgreSQL, peut-être ?

Plus sérieusement, je trouve que les solutions comme le cache utilisateur d'APC sont excellentes et tellement pratiques. Elles permettent par exemple de ne pas utiliser la base de données pour la lecture choses importantes (les cartes, par exemples). Ainsi, quand on effectue une modification, on écrit dans la mémoire et dans la base de données, mais on ne lit que dans la mémoire. Quand l'information n'existe pas en mémoire, on la récupère en base de données puis on la stock en mémoire, ça fait que l'application n'est pas gênée pour reprendre après un crash.

Au prix actuel des serveurs dédiés (10€/mois chez Gandi.net), ça vaut le coup.


Sephi-Chan