Alors, je vais tâcher de répondre dans l'ordre :
Pas de problème de maintenabilité, en toute franchise.
On est dans ce cas-là :
Si le joueur a modifié son cookie (cookie unique d'ailleurs, qui contient absolument toutes les données de la session) et que ce cookie n'est pas valable (donc mauvaise signature), la session est détruite.
Niveau surcharge réseau et taille cookies on doit être bon car j'ai une quinzaine d'éléments stockées en session, qui comportent en gros des int.
Maintenant pour le sniff de cookies, c'est vrai que c'est un problème que je n'avais pas réalisé, tellement obstiné par les vols de session..
Ensuite, j'ai bel et bien mes ressources qui sont en session. Du coup si quelqu'un réussit à modifier le cookie, il peut avoir autant de ressources qu'il souhaite. Là est mon problème.
Continuons :
Au départ, c'était parce que je les croyais plus sûr malgré que ce soit stocké chez le client. Je pensais pouvoir éviter le vol de session avec ce système.
C'est la première fois que j'utilise ce principe, et j'hésite fortement là ^^
Malheureusement, ce n'est pas qu'informatif. J'utilise les données du cookie pour ENSUITE sauvegarder en BDD.
Comme dit plus haut, si le cookie vient à être modifié correctement, le joueur peut obtenir toutes les ressources qu'il souhaite.
______________________
Concernant l'optimisation :
J'aurai dû être plus clair concernant les avantages de ce système. Je ne considère pas que ce soit de la 'nanoptimisation' car ce mécanisme m'évite non pas UNE requête à la BDD, mais plus d'une dizaine sur chaque page ainsi que des calculs.
Exemple :
J'ai pour limiter le nombre de bâtiments une système de cases.
Le joueur a ainsi 40 cases disponibles au début du jeu, qu'il peut étendre via des extensions.
Chaque bâtiment occupe un certain nombre de cases, définit dans une base de données externe (de référence, communes à tous les serveurs).
Pour déterminer le nombre de cases occupées / disponibles, rien n'est stocké en BDD. Le tout est calculé à chaque initialisation de la session, construction de bâtiment etc, selon le principe :
Cases totales = Cases initiales + extensions (extensions stockées en BDD)
Cases occupées = Parcours de TOUS les bâtiments du joueur (stockées dans plusieurs tables), puis calcul. Ce calcul requiert d'aller chercher le nombre de cases qu'occupe chaque bâtiment dans ma base de référence.
Cases libres = Cases totales - Cases occupées
Puis je stocke ces infos en session. Du coup quand je construis un bâtiment, afin d'éviter de refaire X requêtes à la BDD, j'interroge la session pour savoir s'il a assez de cases disponibles.
Et j'ai plusieurs ressources gérées comme cela.
Donc le gain est réel si 100 membres actualisent la page toutes les 2 secondes, inutile si personne ne refresh jamais.
Citation :Si ce système implique que la BDD n'est pas à jour (c'est à dire que certaines données sont dans les sessions, d'autres dans la BDD, etc), alors cela risque de rendre le tout impossible à maintenir...En fait, tant que l'utilisateur ne fait pas d'action qui modifie d'une façon ou d'une autre les ressources, tout est calculé et affiché en fonction de la session. Si une valeur vient à être modifiée fortuitement (dépense, achat, pillage, etc), alors on recalcule depuis la session et on enregistre le tout en BDD.
Pas de problème de maintenabilité, en toute franchise.
Citation : • Si c'est un mix des deux, et que les données sont stockées coté client, dans un cookie, et que le serveur ne stocke que la signature du cookie (pour vérifier qu'il n'a pas été modifié), alors on doit être correct niveau sécurité.
→ On aura toujours le problème de la surcharge réseau, de la limite de taille des cookies, et de la possibilité de se faire sniffer ses cookies.
On est dans ce cas-là :
Si le joueur a modifié son cookie (cookie unique d'ailleurs, qui contient absolument toutes les données de la session) et que ce cookie n'est pas valable (donc mauvaise signature), la session est détruite.
Niveau surcharge réseau et taille cookies on doit être bon car j'ai une quinzaine d'éléments stockées en session, qui comportent en gros des int.
Maintenant pour le sniff de cookies, c'est vrai que c'est un problème que je n'avais pas réalisé, tellement obstiné par les vols de session..
Ensuite, j'ai bel et bien mes ressources qui sont en session. Du coup si quelqu'un réussit à modifier le cookie, il peut avoir autant de ressources qu'il souhaite. Là est mon problème.
Continuons :
Citation :La question que je me pose est "pourquoi un cookie et pas une session ?" et je rejoins Xenos sur ses remarques.
Au départ, c'était parce que je les croyais plus sûr malgré que ce soit stocké chez le client. Je pensais pouvoir éviter le vol de session avec ce système.
C'est la première fois que j'utilise ce principe, et j'hésite fortement là ^^
Citation : Si j'en crois le premier paragraphe, il s'agit de garder en mémoire les ressources et leur évolution. Ce n'est qu'informatif.
Si j'en crois le second paragraphe, ce n'est plus informatif : en modifiant la session le joueur peur avoir un gain : quel est-il ?
Malheureusement, ce n'est pas qu'informatif. J'utilise les données du cookie pour ENSUITE sauvegarder en BDD.
Comme dit plus haut, si le cookie vient à être modifié correctement, le joueur peut obtenir toutes les ressources qu'il souhaite.
______________________
Concernant l'optimisation :
J'aurai dû être plus clair concernant les avantages de ce système. Je ne considère pas que ce soit de la 'nanoptimisation' car ce mécanisme m'évite non pas UNE requête à la BDD, mais plus d'une dizaine sur chaque page ainsi que des calculs.
Exemple :
J'ai pour limiter le nombre de bâtiments une système de cases.
Le joueur a ainsi 40 cases disponibles au début du jeu, qu'il peut étendre via des extensions.
Chaque bâtiment occupe un certain nombre de cases, définit dans une base de données externe (de référence, communes à tous les serveurs).
Pour déterminer le nombre de cases occupées / disponibles, rien n'est stocké en BDD. Le tout est calculé à chaque initialisation de la session, construction de bâtiment etc, selon le principe :
Cases totales = Cases initiales + extensions (extensions stockées en BDD)
Cases occupées = Parcours de TOUS les bâtiments du joueur (stockées dans plusieurs tables), puis calcul. Ce calcul requiert d'aller chercher le nombre de cases qu'occupe chaque bâtiment dans ma base de référence.
Cases libres = Cases totales - Cases occupées
Puis je stocke ces infos en session. Du coup quand je construis un bâtiment, afin d'éviter de refaire X requêtes à la BDD, j'interroge la session pour savoir s'il a assez de cases disponibles.
Et j'ai plusieurs ressources gérées comme cela.
Donc le gain est réel si 100 membres actualisent la page toutes les 2 secondes, inutile si personne ne refresh jamais.