Javascript a de nombreux avantages (open, indépendant d’un os, beaucoup utilisé, …), c’est pourquoi je milite pour que les développements dans le monde de l’éducation puissent aussi reposer dessus c’est possible, (j’en ai fait la preuve avec edba, lire cet article) et donnent lieu à des applications sous forme de pages web autonomes (seul besoin pour les faire fonctionner coté utilisateur : un navigateur web et une connexion au réseau ; coté développeur, une fois développée, la page web peut être déposée sur un serveur web minimal). Cependant, jusqu’à maintenant, j’avais un doute : très souvent, l’utilisation de javascript ne prends pas en compte les possibles tentatives de fraude et il s’avère qu’il est assez souvent facile d’arriver à répondre à un quizz, un qcm, … sans connaitre la réponse mais en allant chercher dans le code quelle est la réponse attendue. C’est particulièrement vrai pour des pages reposant uniquement sur javascript. Une solution pour éviter cela consiste à introduire un peu de PHP dans l’application, code déposé sur le serveur pour y faire l’analyse des réponses (laisser le javascript sur le poste client analyser les réponses, c’est prendre le risque de laisser la main à l’utilisateur pour qu’il regarde comment l’analyse se fait, ou la simuler pour voir le résultat, ou … -toute méthode de reverse engineering qui permet de retrouver les réponses), le code sur le serveur est inattaquable (enfin, presque …) et assure la sécurité du système. L’inconvénient, c’est que le projet n’est plus totalement open, qu’il ne peut plus tenir dans une page web unique et qu’il faut connaitre javascript+php pour le développer. Cela fait beaucoup.
Un autre soucis avec Javascript concerne des projets plus gros qui auraient besoin d’un base de données centralisée sur un serveur (il y en a, et particulièrement dans le domaine de la recherche où l’on veut conserver une trace de l’activité pour en faire l’analyse). Tout faire en javascript semble difficile car l’accès aux bases de données se fait en général à partir des serveurs et non des clients (et donc à nouveau en php, par exemple), ou à partir d’application standard (hors navigateur) pour avoir des droits étendus sur l’accés au réseau (ou au disque dur). Pour les applications web tenant dans une page web, c’est à dire pour les application web fonctionnant dans un navigateur, cela passe par une partie du code sur le client (en général javascript), et une partie sur le serveur (en général php). Pour diverses raisons, et en particulier des raisons de sécurité, la part php est inévitable et ne se réduit pas à laisser rebondir la demande javascript directement vers le serveur. Pour certaines requêtes sur la base de données, le simple rebond est possible : pour la consultation des parties publiques de la base, par exemple ; pour d’autres requêtes un petit problème de confidentialité peut surgir : consultation d’informations personnelles ; pour d’autre encore, c’est un trop gros problème pour imaginer utiliser un simple rebond : par exemple pour l’accès en écriture/modification/suppression sur l’ensemble de la base (par erreur ou à dessein, un utilisateur peut alors altérer/détruire le contenu de la base).
Faut-il se résoudre à apprendre php … ? Non, pas nécessairement … Pour les problèmes de triches aux QCM, il y a moyen de compliquer un peu le code d’évaluation d’une réponse à un test pour que le reverse engineering soit difficile (sans que le travail demandé pour la modification de code soit très importante) : ne pas mettre en clair la réponse (éventuellement la coder, mais cela ne suffit pas toujours), au lieu d’analyser une seule réponse à la fois, il est préférable d’en prendre plusieurs en même temps (la combinatoire des réponses possibles est alors plus grande et ne peut être testée par essai/erreur), et utiliser une fonction asymétrique (type MD5) pour voir les résultats. Ce sera un résultat global, avec un mécanisme de type code-correcteur, on peut à partir de plusieurs résultats globaux de ce genre identifier le nombre d’erreur, et selon la méthode employée localiser les erreurs (mais alors il y a moyen de faire du reverse engineering). Pour l’accès au base de données, la solution vient d’un travail d’identification de la demande avec mot de passe, mais attention, un vrai identification, et qui prend en compte le fait que le code javascript est visible : cela peut se faire avec un système à clé publique (comme pour rsa). La bonne nouvelle, dans un cas comme dans l’autre, c’est que les algorithmes un peu compliqués (MD5, RSA) sont disponibles en javascript (il y a beaucoup de choses en javascript, c’était dèjà une bonne nouvelle il y a quelques années) :
exemple : essayer de trouver les dates de naissance/mort de Alan (pour la naissance, aide : regarder le code, pour la mort, aide ???). Autre exemple avec des réponses booléennes : essayer de trouver le sexe de ces anges (aide : regarder le code), ou de savoir si ceux-ci ont fait avancer l’informatique ( aide ???). Quand il n’y a pas d’aide immédiate (« aide ??? »), i.e. quand regarder le code ne suffit pas, il reste toujours la méthode dite « brutale » qui consiste à tout tester … lorsque le « tout » ne comporte qu’une dizaine de cas, l’étude exhaustive peut se faire à la main ; lorsque le « tout » comporte plusieurs milliers de cas, un programme peut le faire ; lorsqu’il y a des milliards de milliards de cas à voir, … ???
