+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Défi sécurité. (/showthread.php?tid=2359)
RE: Défi sécurité. - Sephi-Chan - 05-02-2008
Je pense aussi que les transactions peuvent t'être utiles.
Il y avait aussi la possibilité de définir une variable de session au début de script et le script se lance quand elle existe, puis il la détruit à la fin. Ainsi, à la manière d'un verrou, on ne peut pas effectuer l'action tant que celle de la première pas n'a pas été détruite. J'ignore toutefois si c'est fiable.
Sephi-Chan
RE: Défi sécurité. - Roworll - 05-02-2008
En considérant que si j'accède au site avec 3 navigateurs différents (Opera, IE et FF) j'ai trois environnement de session différents, la protection via variable de session ne parait pas optimale.
Ou alors il faut être sur et certain que le joueur n'est connecté qu'avec un seul navigateur.
RE: Défi sécurité. - uriak - 05-02-2008
Ha j'avais donc vu juste
hier soir je n'avais toujours pas récupéré le net :'(, et j'ai continué à réfléchir. De mon côté j'avais une faille majeure dans mon code en cours de conception, et j'avoue que le problème est semblable. Utilisant la session pour éviter certaines tests, je ne peux pas me permettre qu'un joueur possède deux sessions... mais insérer dans la table le fait que la session est prise peut échouer si on tente de se logguer simultanément de deux navigateurs. Sinon, il ne me reste qu'à faire des check en base pour toutes les actions, pff Je me sens découragé de sentir que les tricheurs obligent à bousiller l'optimisation de la charge d'un site.
L'autre technique serait de toujours valider d'abord l'aspect désagréable d'une transaction, avant le bonus. Ou alors prévoir un système d'annulation interne, mais vive les doubles requêtes SQL. Je vais plutôt voir du côté des transactions, ça m'a l'air plus sensé.
RE: Défi sécurité. - Amrac - 05-02-2008
Les transactions mangent aussi les performances..
Et puis ca oblige à retoucher énormément de code...
Limiter a une session pourrait sembler être une solution, mais ca peut vite être casse couille pour l'utilisateur s'il se déconnecte mal et qu'il se retrouve oblige d'attendre que l'ancienne session meurt...
RE: Défi sécurité. - uriak - 05-02-2008
Le mieux serait donc de se débrouiller pour qu'en cas d'embrouille, l'appel provoque le plus souvent une situation désagréable (disparition d'armée) afin que les tricheurs ne prennent pas le risque.
Pour ce cas particulier il y a une autre solution : ne pas détruire/créer d'armée, mais l'affecter à une attaque ou à un joueur. Il n'y a plus de "créer" ni de "DELETE" seulement un "UPDATE" qui s'il est appelé 2 fois ne sera pas dramatique. Par contre ça oblige à réviser le schéma SQL derrière...
RE: Défi sécurité. - keke - 05-02-2008
Coucou,
pour Mysql, je sais pas, mais supposons que vous utilisiez ORACLE, VOus pourriez faire appel à un bout de code comme celui là, (trouvez sur dévelopez.com)
Citation :BEGIN
INSERT INTO Tent VALUES (9, 'Uranus', 4, 'High-standing Tent 4 places');
INSERT INTO Tent VALUES (2, 'Neptune', 2, 'Simple Double Tent');
EXCEPTION
WHEN OTHERS THEN ROLLBACK;
END;
Dans cet exemple simple, si un INSERT plante (pour une contrainte d'intégrité par exemple), aucune action n'est réalisée.
Est-ce que cela pourrait résoudre le problème ? Ce type de requête est-il disponible avec vos systèmes de BDD (MYSQL, oracle, db2, sql server, sybase, ...) ?
Kéké, inquiet car potentiellement des failles de sécurités peuvent exister sur Magdales ... encore que j'aimerais le constater.
RE: Défi sécurité. - uriak - 05-02-2008
c'est le concept d'une transaction, à ce que je découvre. Mais en pratique c'est pas si simple : dans beaucoup de cas, il ne faut pas executer deux requêtes atomiques, mais faire une vérification puis une requête. Bref il faut écrire une requête qui serve d'intérrupteur. Je ne sais pas si c'est simple.
RE: Défi sécurité. - pascal - 05-02-2008
bienvenue dans le monde du transact SQL
les transactions ça marche, sinon on n'aurait pas le système bancaire actuel ( hors SG, bien sûr )
A+
Pascal
RE: Défi sécurité. - Amrac - 05-02-2008
J'ai étudié les transactions pendant mon DUT, ma conclusion était que si tu voulais absolument aucun risque d'accès simultané, c'était possible, mais ça coute une fortune en ressource perdus...
RE: Défi sécurité. - uriak - 05-02-2008
bon on va dire que dans un jeu où il est difficile de spammer les commandes, autant se préoccuper d'autres failles avant celle d'atomicité
Et pour info, qu'as-tu choisi de faire, finalement ? (concernant les joueurs et le code )