Parenthèse: 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...
Tout dépend de la façon de le réaliser.
• Si c'est un cookie qui stocke des données du joueur (ressources, batiments, etc), qu'il stocke sa propre signature (type sha256 avec un sel), et que le serveur le lit, le désérialise, vérifie sa signature et si elle correspond, considère les données du cookie comme légitimes, alors
→ le risque est important: des joueurs s’octroieront des ressources en modifiant ce cookie
→ le réseau sera surchargé: le cookie étant envoyé à chaque requête HTTP, le réseau sera ralenti et le bénéfice sera peut-être moindre
→ la taille des cookies est limitée: il ne faudra pas trop stocker de données dans le cookie
→ le cookie peut être intercepté: si la connexion n'est pas sécurisée, un pirate connaitra toutes les ressources des comptes qu'il sniffera
• Si les données sont stockées dans la session coté serveur (type $_SESSION[]), et que le joueur est rattaché à sa session via un cookie de session classique, alors, pourquoi pas, le système semble fiable.
→ Est-ce bénéfique du point de vue des perfs (car les sessions PHP sont stockées sur le disque, il me semble, et peuvent donc être plus lentes d'accès que des données SQL qui cache en RAM les derniers résultats), cela reste à voir.
• 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.
• Tout ce qui est données critiques est géré par le serveur.
→ données personnelles (email)
→ données de sécurité (pass)
→ données critiques du jeu (ressources des joueurs, unités,...)
• Le serveur peut partiellement déléguer une tâche au client et se contenter de vérifier le résultat proposé par le client
→ un algorithme de pathfinding en javascript, coté client, cherche le plus court chemin du point A au point B
→ il envoie ce chemin au serveur
→ le serveur se contente de vérifier la validité du chemin
→ le serveur se moque de savoir si le chemin envoyé par le client est le plus rapide ou non
Cela permet de décharger le serveur (il ne fait pas l'algorithme de calcul de chemin) sans rogner sur la sécurité (le serveur s'assure que le chemin est valide). Les preuves de travail fonctionnent sur ce principe.
• Le serveur peut déléguer totalement une tâche au client
→ agencement de la page du site
→ présentation (CSS)
→ toute donnée qui n'impacte en rien les autres joueurs (statistiques personnelles du joueur, comme le temps total de jeu)
Tout dépend de la façon de le réaliser.
• Si c'est un cookie qui stocke des données du joueur (ressources, batiments, etc), qu'il stocke sa propre signature (type sha256 avec un sel), et que le serveur le lit, le désérialise, vérifie sa signature et si elle correspond, considère les données du cookie comme légitimes, alors
→ le risque est important: des joueurs s’octroieront des ressources en modifiant ce cookie
→ le réseau sera surchargé: le cookie étant envoyé à chaque requête HTTP, le réseau sera ralenti et le bénéfice sera peut-être moindre
→ la taille des cookies est limitée: il ne faudra pas trop stocker de données dans le cookie
→ le cookie peut être intercepté: si la connexion n'est pas sécurisée, un pirate connaitra toutes les ressources des comptes qu'il sniffera
• Si les données sont stockées dans la session coté serveur (type $_SESSION[]), et que le joueur est rattaché à sa session via un cookie de session classique, alors, pourquoi pas, le système semble fiable.
→ Est-ce bénéfique du point de vue des perfs (car les sessions PHP sont stockées sur le disque, il me semble, et peuvent donc être plus lentes d'accès que des données SQL qui cache en RAM les derniers résultats), cela reste à voir.
• 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.
• Tout ce qui est données critiques est géré par le serveur.
→ données personnelles (email)
→ données de sécurité (pass)
→ données critiques du jeu (ressources des joueurs, unités,...)
• Le serveur peut partiellement déléguer une tâche au client et se contenter de vérifier le résultat proposé par le client
→ un algorithme de pathfinding en javascript, coté client, cherche le plus court chemin du point A au point B
→ il envoie ce chemin au serveur
→ le serveur se contente de vérifier la validité du chemin
→ le serveur se moque de savoir si le chemin envoyé par le client est le plus rapide ou non
Cela permet de décharger le serveur (il ne fait pas l'algorithme de calcul de chemin) sans rogner sur la sécurité (le serveur s'assure que le chemin est valide). Les preuves de travail fonctionnent sur ce principe.
• Le serveur peut déléguer totalement une tâche au client
→ agencement de la page du site
→ présentation (CSS)
→ toute donnée qui n'impacte en rien les autres joueurs (statistiques personnelles du joueur, comme le temps total de jeu)