Défi sécurité.

[keke]

Une solution pourrait-elle être d'avoir un serveur de meilleur qualité pour éviter des problèmes de latence ?
N'existe-t-il pas une option Apache ne tolérant qu'un seul traitement à la fois ?

J'avoue que je suis pas assez calé dans le domaine pour l'appréhender correctement, mais il serait interressant pour tous de trouver une (la) solution la plus optimum.

kéké.
PS : Il est vrai que les tricheurs sont malins, mais l'idée n'est pas tant de blinder son application contre toute triche, que de mettre en place un système pour les repérer. Quelques exemples sur mon jeu : le multi-compte n'est pas interdit, mais toutes mes fonctions sont prêtes pour les détecter ; La progression (xp, carac, argent) des joueurs est sauvegardé régulièrement. Je peux ainsi rapidement voir les joueurs qui gagnent trop et tracer leurs historiques (sur 7 jours).

[uriak]

Et comment faites-vous pour tracer la progression ? Des tables avec entrée à chaque date ? des fichiers de logs ?

[Roworll]

De mon coté, je stocke dans des fichiers textes au format CSV.
Pour l'analyse,; il me suffit de récupérer le fichier puis de l'importer via Excel pour travailler dessus.

[keke]

Base de donnée avec joueur, jour, avancement dans chaque domaine (sous format numérique).

Depuis migration GET -> POST je n'ai pas vu de joueur tricher ... mais je recoupe pas les multi-comptes ...

Salut !
Kéké.
PS : j'évite autant que possible le fichier plat.

[NicoMSEvent]

j'évite autant que possible le fichier plat.

surtout que excell est limité a 65.535 lignes... (je dépasse les 100.000 lignes de log par mois :p)

pour le moment, je trace que la durée d'exécution des requetes, leurs fréquences, et celles qui ont échoués.

[Roworll]

Pour le moment, j'atteins péniblement les 200 lignes par semaine (Version de Developpement oblige)
Comme il est vrai que Excel est limité, j'ai prévu d'utiliser LogParser pour la suite.

Je m'en suis déjà servi au boulot, c'est assez cool.

[Amrac]

Pour tracer la progression, je charge en local les sauvegardes de ma base de données et j'ai un script qui switch entre les sauvegardes pour comparer ce que le joueur possède à différent moment et déterminer si c'est possible ou non.

Sinon pour la solution:

Une solution pourrait-elle être d'avoir un serveur de meilleur qualité pour éviter des problèmes de latence ?

Ca signifierais que tu sois obligé de baisser la charge maximal de tes serveurs. Tu augmente donc significativement ton ratio Joueurs/Dépense serveur.

De plus, ca ne ferait que réduire la probabilité que ca ce produise. Même si tu as un très bon serveur, les joueurs risque de te le saturer quand même en spammant.

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...

L'idée est bonne, mais comme tu le dis, c'est du boulot, et ce n'est valable qu'ici...

Comme possible solution je retient:
-Les transactions. Je les utiliserais personnellement sous forme de "mini-transaction". Le select et le delete à la suite.
-En cas de problème, s'arranger pour que la situation soit défavorables aux joueurs. Ca diminue de façon drastique les tentatives, mais par contre vous allez avoir de temps en temps des innocents qui vont se plaindre sur votre forum. (vécu)
-Effectuer les deletes immédiatement aprés le select quand c'est possible (ca rejoin un peu le premier point).

Aprés réflexions, voici la solution que je vais implémenter:
En début de script, avant même la connexion à la BDD, j'instaure un système de vérou via la session.
Le script ressemblera globalement à ca:

Code PHP :

<?php 

if(isset($_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']])) //Si on à déjà accéder à cette page.

{

    if($_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']] > time()) //Si le verrou est encore fermé, il s'agit d'un spam

    {

        echo 'Merci de patienter, traitement en cours.';

        $_SESSION['penalite']++;//A chaque spam, je lui met une seconde d'attente en plus.

        exit();//On casse l'execution de la page.

    }

}

//Si on arrive jusqu'ici, alors le verrou n'est pas fermé. On enregistre la date d'expiration du nouveau verrou, en prenant en compte les éventuels pénalitées.

$_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']] = time() + 2 + $_SESSION['penalite']; 

[Plume]

Je trouve que c'est plutôt ingénieux. Pour ma part, je ne vois pas de contre à cette mesure. Peut-être que d'autre trouveront quelque chose. Les ID de sessions sont couramment utilisés. Donc là par contre, c'est pas trop trop inconnu

Pour les charges serveurs, après les changements, avertis de la mesure que tu as prises en évoquant les sanctions encourues à chaque tentative de triches. Trace les actions à ce niveau pour le repérage, mais j'crois savoir que tu le fais déjà

L.

[NicoMSEvent]

Je vais y ajouter un système de session unique. Finit les doubles (voir triple) session pour tout péter.
Le principe est simple, chaque session posséde un Identifiant de session, lors de la connexion d'un joueur, j'enregistre l'identifiant de session du joueur dans la base de données.
A chaque page, je vais vérifier que l'identifiant de session correspond toujours a celui inscrit dans la BDD. Si ce n'est pas le cas, je lui affiche un message d'erreur du style "Quelqu'un viens de se connecter sur votre compte.", et je détruit sa session.

ça j'utilisais déjà pour éviter que quelqu'un soit connecté 2x à deux endroits différents.

Les id de sessions me servent aussi pour détecter les multi-comptes :
entre 2 connections, je vide la session, mais je ne la détruit pas.
Si la personne se reconnecte avec un autre compte, j'ai 2 comptes avec le même ID de session, et il me suffit de rajouter une ligne dans le log quand c'est détecté. C'est aussi bête que ça

[LittleQI]

Je viens proposer ma solution.
Dans tous les autres langages quand on ne veut pas qu'un script soit executé 2 fois en meme temps, on utilise tout simplement les MutEx (Exclusion Mutuelle). Hors à ma connaissance pas de MutEx en PHP mais par contre il y a les Sémaphores (et le MutEx n'est rien d'autre qu'un semaphore binaire).

Il suffit de s'en servir ainsi

Code PHP :

<?php 

$semaphore = sem_get(1); //on recupere la semaphore qui a la clef 1



sem_acquire($semaphore); //on essaye de recupérer le semaphore, si celui ci est deja pris, le code patientera ici jusqu'à ce qu'il se libère



//ici le code critique



sem_release($semaphore); //on libère le semaphore pour qu'unautre utilisateur puisse le récupérer