Partage
  • Partager sur Facebook
  • Partager sur Twitter

[Conseil] Quel autre langage utiliser ?

Langage côté client.

Sujet résolu
    12 mai 2010 à 12:24:47

    Bonjour, bon après de multiples recherches infructueuses je poste un sujet pour vous demander conseils.

    Je connais le html, php, javascript y'a pas de problème pour ça. Sans rentrer dans les détails je vais expliquer ce que je veux.
    Je voudrais faire un jeu en ligne un peu complexe par navigateur, sauf que vu le nombre de variables et de conditions qui rentrerait en compte pour joueur connecté ça fera beaucoup trop à gérer pour le serveur si je met tout ça en php.

    Donc j'ai pensé à écrire une partie de php pour des informations cruciales, inaccessibles par des post ou get donc pas de tricheries si c'est bien fait.
    Puis une grosse partie des calculs et conditions (attaque, pv, distance, défense, niveau, le tout géré avec des intervalles de temps donné) en javascript comme ça côté client ça laissera le serveur respirer.

    Le problème c'est qu'il serait pas difficile pour un programeur de modifier le script js de son côté et de ne pas toucher mes variables mais d'en créer d'autres qu'il utilisera à la palce de mes variables.

    Par exemple si je défini le max de pv d'un joueur avec var_maxPV = 300 et que j'utilise cette variable partout , s'il crée une variable var_faux_maxPV = var_maxPV + 50000 et qu'il utilise cette variable dans toutes les autres fonction où ma variable est sensée être utilisée, je n'ai trouvé aucun moyen en php pour vérifier que mon js n'a pas été modifié.




    Alors Question :
    Est-ce qu'il y a un moyen de vérifier que le js n'ait pas été retouché ou alors est-ce qu'il existe un langage côté client et "sécurisé", pour faire en sorte d'éviter les tricheries ?
    Je suis attentif à toute solution, ça m'éviterait de programmer trop loin pour me rendre compte que tout ce que j'ai fait peut être hacké sans problème.
    • Partager sur Facebook
    • Partager sur Twitter
      12 mai 2010 à 12:36:53

      Il n'existe aucun langage client sécurisé (Rien que de le dire c'est un pléonasme :o)

      "Never trust user input", si c'est coté client, c'est pas sécurisé, c'est tout :)

      Mais tu sais, un serveur c'est fait pour travailler... Les serveurs sont beaucoup plus résistant que ce que vous pensez ^^

      Et puis si t'as un doute, le mieux reste une comparaison des microtime(true); en php entre le début et la fin de ton script, tu verras que tu seras souvent < 0.01
      • Partager sur Facebook
      • Partager sur Twitter
        12 mai 2010 à 12:53:13

        Je sais pas si je dois pleurer ou dire merci alors je vais faire les deux.
        Je m'attaque à le programmer tout en php alors et merci pour l'info sur microtime je connaissais pas.
        Je mets le sujet en résolu mais si quelqu'un veut reposter derrière ça n'hésitez pas.
        • Partager sur Facebook
        • Partager sur Twitter
          12 mai 2010 à 13:02:26

          On peut aussi essayer de "compliquer" le code Javascript, par exemple en le réduisant au strict minimum. Voir à ce sujet http://code.google.com/intl/fr-FR/speed/page-speed/docs/payload.html#MinifyJS.

          Bien entendu ce n'est pas "plus" sécurisé...
          • Partager sur Facebook
          • Partager sur Twitter
            12 mai 2010 à 13:21:44

            Citation : cooc

            On peut aussi essayer de "compliquer" le code Javascript, par exemple en le réduisant au strict minimum. Voir à ce sujet http://code.google.com/intl/fr-FR/speed/page-speed/docs/payload.html#MinifyJS.

            Bien entendu ce n'est pas "plus" sécurisé...


            Inutile et stupide.

            Par contre, si tu choisis bien les infos cruciales, tu peux éviter de trop charger ton serveur (même si c'est pas près d'arriver).
            Il faut que les variables JS ne servent que d'interface. Les nombres aléatoires et les possibilités d'actions doivent êtres déterminées par le serveur. Ensuite, il dit au JS ce qu'il a le droit de faire. Le client décide et le JS dit ce qui a été décidé. Et on recommence.

            Pour illustrer, disons que tu recode pokémon.

            Le serveur envoie toutes les infos (pokémons, lvls, objets disponibles etc.).
            J1 a le choix entre plusieurs actions et il accède aux différents attaques, objets et autres sans rien demander au serveur vu que le JS gère tout avec les infos qu'il a reçu.
            J1 décide d'attaquer.
            Le serveur lui dit s'il a fait un coup critique ou non et les dégâts subits. Le JS et le serveurs font les calculs pour avoir les nouveaux PV et PP et les stockent (ainsi, le serveur continue d'avoir les valeurs et on ne peut pas lui en envoyer des fausses). (L'intérêt que les deux calculent est que ça évite de foutre trop de données dans la requête Ajax).
            Et ça repart.

            Si on met n'importe quoi dans les variables JS, ce n'est que l'action faite qui est prise en compte par le serveur qui vérifie si elle est possible et renvoie les changements. Bref, on ne peut pas tricher.
            • Partager sur Facebook
            • Partager sur Twitter
              12 mai 2010 à 13:29:47

              Ouais enfin, "Il accède aux objets sans rien demander au serveur", le serveur doit quand même après dire si l'action était autorisé ou non.

              @Abysse: Par contre, moi, je fais un mmorpg en javascript. Pour les déplacements, le php "n'intervient pas", le joueur bouge, ça appel un fonction javascript qui le déplace.

              Et après, tout les x temps, les déplacements effectués sont envoyé au serveur.

              A ce moment là, mon serveur revérifie tout :
              - Il prend la dernière position qu'il connait
              - Il compare au premier déplacement envoyer, si il est [-1;+1] autour de la position actuelle, c'est un déplacement autorisé donc il dit rien
              - Puis il fait ça avec tout les déplacements envoyés.

              Et il compare la quantité de déplacement par rapport au temps écoulé depuis la dernière requête, si le joueur envoi 20 déplacements, en 5 secondes par exemple, il y a une erreur.

              Si il trouve une irrégularité, il kill le joueur purement et simplement et il n'accepte plus rien de l'utilisateur.

              @cooc: Compacté le code c'est bien pour décourager le premier venu, mais après.. ça n'a pas d'utilité (enfin si, réduire la taille du fichier). Personnellement, dans un cas comme ça, je regarde même pas le code javascript, j'ouvre firebug, je vois les requêtes ajax qui passent, les variables qui passent et c'est bon.
              • Partager sur Facebook
              • Partager sur Twitter
                12 mai 2010 à 14:26:04

                oui j'avais bien pensé laisser au moins tout l'affichage en js avec les infos envoyées en php puis peut-être gérer les déplacements en js en vérifiant de temps en temps par php que les actions effectuées ne soient pas hors limite sinon ban. Je verrai ça une fois que j'aurai écrit assez de php et si ce que j'ai à dire est intéressant je ressusciterai ce post ^^ .
                • Partager sur Facebook
                • Partager sur Twitter

                [Conseil] Quel autre langage utiliser ?

                × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                • Editeur
                • Markdown