Securisation du serveur PHP 

La page utilisée par le magicien

La page magicien.html contient une barre de navigation située en haut de page qui permet d’accéder aux différentes pages de l’application : création et Domus. Lorsque l’utilisateur clique sur l’un des onglet, la fonction « page() » est appelée. Cette fonction prend un paramètre « demande » qui contient le nom de la page demandée. A l’aide de « document.location.href », nous pouvons rediriger l’utilisateur vers la page demandée.
Cependant, le problème de l’adresse IP se pose ici aussi puisque l’adresse entrée devra contenir l’adresse IP.
Sur cette page nous trouvons une partie comprenant une palette de couleur. Celle-ci a été faite à l’aide du site openclassrooms.com sur laquelle il y avait un cours pour apprendre à créer une palette de couleur en HTML et JavaScript. La barre de choix et le dégradé de couleur sont deux images qui se trouvent dans le dossier « images », tout comme les images des deux curseurs correspondants. Grâce à la feuille CSS magicien.css, la palette a été positionnée à l’endroit voulu. Les différents traitements se font ensuite en fonction des coordonnées x et y de la souris de l’utilisateur que nous récupérons à l’aide de la fonction « position(axe,event) ».
C’est ensuite dans la fonction « calcul(event) » que se passent les différents traitements permettant d’afficher les couleurs correspondantes calculées en RGB. Grâce à la fonction « clique(objet) » appelée dès que l’utilisateur clique sur un élément, nous pouvons savoir s’il clique sur la barre de couleur (clic) ou sur le carré de dégradé (clic2). Par la suite, si l’utilisateur a cliqué sur la barre de couleur, différents traitements dépendants des coordonnées x et y de la souris sont opérés pour afficher le carré de dégradé avec la couleur correspondante à celle choisie dans la barre de dégradé. Cette dernière étant découpée en 6 parties égales d’où les 6 boucles if en fonction des coordonnées y (car la barre est positionnée à la verticale).
La barre faisant 300 pixels de hauteur au total, un traitement différent est appliqué tous les 50 pixels.
A chaque 6ème seul un des 3 paramètres RGB est modifié en fonction des coordonnées y de la souris. Dans le premier 6 ème c’est le bleu qui est modifié et le rouge et le vert gardent la même valeur peu importe où l’on clique dans ce 6ème . Une fois ce calcul effectué, on applique la couleur RGB trouvée au carré de dégradé.
Pour afficher la couleur choisie dans le carré de dégradé dans le petit rectangle d’aperçu, la fonction « afficher() » est appelée. Tout comme pour la fonction précédente, la couleur choisie est calculée en fonction des coordonnées x et y du clic de la souris. Le pourcentage de noir et de blanc est calculé puis appliqué successivement au rouge, au vert et au bleu pour obtenir la couleur voulue.
La fonction « hexadecimal() » est utilisée pour convertir la couleur RGB en hexadécimal. Cette étape est réalisée pour l’affichage du code de la couleur en hexadécimal plutôt qu’en RGB. L’hexadécimal étant plus largement utilisé. Lorsque l’utilisateur a choisi sa couleur, il clique ensuite sur le bouton « ok » et la fonction « valider() » est alors appelée. Cette fonction est simplement chargée d’émettre un message « nouvelleCouleur » au serveur qui donnera le code couleur (en RGB) choisi par le magicien pour que le message soit transmis à la page de Domus qui sera chargée de faire la transition de couleur .
Sur la partie droite de la page du magicien se trouvent les différents boutons qu’il pourra actionner. Ils sont classifiés en trois grandes catégories :
 Sons + Mouvements
 Sons seuls
 Mouvements seuls
Ces différentes catégories ont été créées dans le but de pouvoir envisager et permettre le plus possible d’interactions entre le magicien et la page qui se trouvera dans Domus.
Lorsqu’un des boutons est cliqué, la fonction « evenement(data) » est appelée. Cette fonction est chargée d’envoyer un message « message » au serveur qui contient le nom de l’évènement cliqué. Le serveur transmettra ensuite le message par le socket à la page domus.html.
La structure NodeJs utilisée pour le développement de cette application permet ainsi la connexion de plusieurs clients en simultané. Cette fonction permet notamment au magicien de se connecter sur la page de Domus sur une machine en parallèle de celle placée dans Domus pour voir en temps réel ce qui se passe sur la page placée dans Domus, élément indispensable pour le magicien dans le but d’avoir un retour sur ce qui apparait dans Domus.

La page de création

Tout comme dans la page magicien.html, cette page contient la palette de couleur avecses fonctions associées. Pour le bon fonctionnement de cette page et pour permettre les actions voulues, les différentes fonctions associées ont été modifiées. En effet, la fonction « clique(objet) » ne contient plus seulement les deux variables « clic » (pour la barre) et « clic2 » (pour le carré de dégradé) mais également la variable « clic3 » qui est modifiée lorsque l’utilisateur modifie la taille de la forme. La fonction « position(axe,event) » reste inchangée.
La fonction « calcul(event) » qui est chargée des différents traitement, a elle été adaptée aux besoins de l’application. Nous avons désormais trois boucles if majeures : une pour « clic », une autre pour « clic2 » et une dernière pour « clic3 ». Les deux premières boucles restent inchangées.
Lorsque l’utilisateur clique sur la barre de taille, la nouvelle taille de la forme est calculée en fonction des coordonnées x du clic de l’utilisateur. Ceci permet ainsi d’avoir un changement de taille progressif, pas saccadé. L’une des premières versions de cette page contenait un traitement de taille saccadé puisque la barre avait été séparée en quatre parties de chaque côté du milieu. En fonction de la partie dans laquelle l’utilisateur cliquait, une nouvelle taille était attribuée. Il s’est donc avéré plus logique de calculer la nouvelle taille en fonction des coordonnées x de la souris sur la barre de taille pour avoir un changement de taille plus progressif par la suite.
Par exemple, lorsque l’utilisateur souhaite rapetisser un rond, la taille est calculée de la façon suivante. Dans un premier temps, on soustrait la coordonnée x du clic de l’utilisateur au milieu (639). Puis on divise ce résultat par quatre. Enfin on soustrait le résultat obtenu au diamètre initial du rond. On obtient alors le nouveau diamètre. La taille de la forme est ensuite actualisée en rappelant la fonction de création du rond « rond(couleur,d,pique1,taille) ». Puis on remet le diamètre « d » et la taille « taille » à 0.
Différents boutons permettent de créer différentes formes :
 Rond
 Carré
 Ellipse
 Triangle
 Rectangle rond
 Etoile
 Etoile ronde
Ces formes ont été choisies pour leur pertinence dans le cadre de cette expérience. Lorsque l’utilisateur clique sur l’un des boutons, la fonction associée est appelée. Admettons que l’utilisateur clique sur le bouton « Rond », la fonction « rond(couleur,d,pique1,taille) » est alors appelée.
C’est à cet endroit que les formes seront dessinées et mises en mouvement si nécessaire. Le même principe de canvas est adopté dans la page domus.html. A chaque dessin d’une forme, il s’agira de récupérer le canvas, d’en effacer le contenu puis d’y redessiner la nouvelle forme. La fonction « getCanvas() » est appelée au chargement de la page. Elle consiste à récupérer le canvas dans une variable.
La partie gauche de cette page est consacrée aux profils. Elle affiche les profils disponibles sous forme de liste. Chaque profil peut être modifié, supprimé ou appliqué à Domus. Les différentes actions ont été expliquées précédemment. Chaque bouton est une image qui se trouve dans le dossier « images ». Cette partie est réalisée à l’aide d’une fonction dans le serveur qui permet de lister les fichiers contenus dans le dossier « css » dans lequel sont rajoutés les nouveaux profils à chaque création.
Le projet ayant évolué au fil du temps, une première version consistait à pouvoir rendre la forme « agressive » en y ajoutant des piques. Il y avait alors une autre barre s’apparentant à la barre de taille qui permettait de régler l’agressivité de la forme. Après discussion avec mes encadrants, cette fonctionnalité s’est avérée inutile et a donc été supprimée. Cependant, le code correspondant a été gardé en commentaire. Il est donc toujours possible de rajouter cette fonctionnalité si un jour elle s’avère nécessaire.

La page affichée dans Domus

Seule la page de Domus ne possède pas la barre de navigation, l’objectif de cette page étant que la personne se trouvant dans Domus ne puisse pas accéder aux outils mis à disposition du magicien. Il est cependant possible depuis cette page de retourner aux autres pages en modifiant l’url dans la barre de navigation.
Cette page comprend uniquement l’affichage de la forme en mouvement sur fond gris.
La couleur du fond a été choisie de façon à ce qu’une forme blanche puisse être clairement visible. La couleur blanche étant l’une des couleurs de forme les plus importantes dans le cadre de cette expérimentation contrairement à la couleur grise. Une forme grise ne pourra donc pas y être distinguée mais si cela est nécessaire, il est toujours possible de changer la couleur du fond dans la feuille de style associée.
La fonction « getCanvas() » est appelée au chargement de la page. Cette fonction est chargée, comme dans la page palette.html, de récupérer le canvas dans une variable mais également de créer et d’afficher la forme par défaut en mouvement. La forme par défaut est donc un rectangle rond (avec les coins arrondis) de couleur bleue. En effet, le choix de ces paramètres a été fait par mon encadrant Romain Magnani, qui suite à son état de l’art sur l’animisme a établi que la forme la plus neutre serait celle-ci.
En ce qui concerne les mouvements de la forme, ils ont été créés sur la base d’animations fournies par mon encadrant. Le mouvement de repos de la forme (mouvement « iddle ») est le grossissement et le rapetissement de la forme à un rythme qui ne fasse pas penser à un battement de cœur. Il a donc fallu créer un mouvement qui ne soit pas rapide et qui effectue une pause avant de commencer à grandir ou à rapetisser.
Deux autres mouvements m’ont été demandé de réaliser : le mouvement « no » et le mouvement « ok ». Le mouvement « no » est un déplacement de la forme de droite à gauche et le mouvement « ok » est le déplacement de la forme vers la droite, vers le haut, vers la gauche puis un retour à sa position initial. Ces mouvements ont été réalisés à l’aide de TweenJs qui permet facilement de récupérer un objet dans le canvas et de changer ses coordonnées (tout en gérant le fait que la forme placée aux coordonnées précédentes soit effacée). De plus, cela permet également de gérer plutôt simplement la vitesse de déplacement de la forme.

Choix des primitives utilisées

Ce test de perception a pour but de récupérer des données et en déduire des tendances au sujet de l’association entre une forme et un son. Nous avons pour cela sélectionné des primitives sonores et visuelles qui permettront de réaliser au mieux le test de perception qui s’appuie fortement sur l’effet Kiki Bouba énoncé précédemment.

Primitives sonores

Ces sons non lexicaux de « pure prosodie », récoltés dans des corpus d’interaction naturels (Audibert, 2008) et très largement sélectionnés, évalués, mesurés et calibrés depuis ont été choisis (si on se réfère par exemple au modèle bidimensionnel de Russel) pour leur variation égale entre leur valence positive/plaisant vs. négative/déplaisant, dont l’hypothèse est que l’analogie avec les formes soit dans arrondi vs. pointu et/ou blanc vs. rouge, et de leur activation passive vs. active, dont l’hypothèse est que l’analogie avec les formes soit dans petit vs. grand. Quant aux analogies entre les morphologies acoustiques et sonores, nous avons choisi des sons selon :
 leur variation de hauteur de la fréquence fondamentale ;
 leur variation de l’amplitude dont l’hypothèse (rappelons que la perception de la variation de la fréquence fondamentale et de l’amplitude sont des perceptions intégrées et croisées, c’est à dire que si l’une augmente on perçoit une augmentation de l’autre)
 leur variation de qualité de voix (dont l’hypothèse est que l’analogie avec les formes soit dans arrondi vs. pointu car nous n’avons pas introduit de vision de texture qui ferait appel à l’analogie du toucher, c’est-à-dire que nous avons contrôlé ce biais inévitable (d ‘inférence du toucher par la perception visuelle) avec des objets tous perçus selon le même aspect (lisse)) ;
Nous donc avons créé des sons « whouaou », « ah », « euh », « Hum » en fonction des paramètres énoncés précédemment.
Ces sons ont été normalisés pour essayer de limiter l’artefact de l’intensité (volume de la voix). En effet, celle-ci était biaisée à cause de la distance du micro qui variait lors de l’enregistrement. Nous avons ainsi gardé les sons originaux et les sons avec l’amplitude normalisée pour tester l’impact de la modification de l’intensité.
La F0 (fréquence fondamentale) a été modifiée. Mais il était important de suivre l’artefact : pour la voix d’homme, la F0 a été baissée, et pour la voix de femme, elle a été augmentée. Le signal naturel a lui aussi été gardé, c’est la F0 modale. La modification de F0 a donc été opérée sur le son naturel et sur le son normalisé.
Nous avons donc un total de 64 sons : quatre sons différents : « wouhaou », « ah », « euh », « Hum2 ». Pour chacun de ces sons nous avons une version masculine et une version féminine (V et R) en prosodie positive et en prosodie négative (POS et NEG). Il y a donc pour chaque son :
 La version originale
 La version originale normalisée
 La version originale non normalisée avec modification de F0
 La version normalisée sans modification de F0
4 (sons) x 2 (genre) x 2 (prosodie) x 2 (F0) x 2 (amplitude) = 64 sons différents.
Nous avons par la suite créé aléatoirement quatre modèles différents d’ordre d’écoute des sons pour ne pas avoir de biais dû à l’ordre d’écoute.

Primitives visuelles

Pour cela, nous avons donc sélectionné trois formes différentes (rond, rond piquant, piquant), deux couleurs (rouge et blanc : une couleur réputée comme plutôt associée au négatif et à la dominance, et une autre plus neutre qui est réputée pour être plutôt neutre voire positive) et deux tailles (petit et grand : le petit sera plutôt considéré comme pas dominant à l’inverse du grand). En créant toutes les combinaisons possibles, nous obtenons ainsi un panel de douze formes qui seront toutes proposées à l’utilisateur à l’écoute d’un son. L’utilisateur devra alors associer une forme (parmi les douze proposées) au son (en fonction de ce que le son lui évoquera). Il devra ensuite donner un indice de confiance, grâce à l’échelle de Likert qui apparait lorsqu’une forme est sélectionnée.
Le choix des formes a nécessité une certaine réflexion car elles ne devaient représenter rien de connu dans l’environnement naturel de l’humain. C’est pourquoi les formes ont été dessinées avec paint.net à l’image de ce que l’on voulait. Il fallait qu’elles soient déstructurées mais sans trop l’être et pour la forme piquante elle devait être agressive mais pas trop non plus.
Dans le but de ne pas stresser les sujets, nous avons permis une écoute illimitée du son, de même pour le choix de forme. Le choix de l’utilisateur sera définitivement validé lorsqu’il aura choisi son indice de confiance et appuyé sur valider.
D’un point de vue technique, le test de perception a été réalisé en PHP, HTML5 etJavaScript. Les données récupérées pour chaque sujet sont stockées dans un fichier CSV global sur le serveur (ouvert à chaque connexion avec le curseur à la fin, pour conserver les données récupérées précédemment). Par précaution, à chaque nouveau sujet, un fichier ayant pour nom son identifiant, est créé. Cela permet de ne pas perdre la totalité des données si le fichier CSV global vient à se perdre par exemple.
A chaque connexion, un identifiant unique est attribué avec la fonction uniqid() de PHP qui permet d’attribuer un identifiant unique préfixé basé sur la date et l’heure de connexion de l’utilisateur. Cet identifiant unique sera placé dans la première colonne du fichier CSV et nous permet de garder l’anonymat des sujets qui ont participés au test tout en les distinguant les uns des autres. Le fichier CSV est rempli à la fin de chaque test (lorsque l’utilisateur clique sur « terminer » après avoir rempli le questionnaire), ce qui implique de garder en mémoire les différentes données récupérées tout au long du test.
Pour réaliser cela, j’ai utilisé des variables de session contenant des tableaux.
Lorsque l’on remplit le CSV, les différents tableaux sont parcourus à l’aide de l’indice des sons (il y a autant de données différentes pour un même paramètre que de sons).
L’envoi des données récupérées en JavaScript est réalisé avec la méthode GET, sauf pour le questionnaire de fin de test (la méthode POST a été utilisée pour plus de facilités) et pour le clic de l’utilisateur pour l’écoute d’un son. Pour écouter le son, un formulaire a été créé. Lorsque l’utilisateur clique sur « Ecouter le son » ou sur le bouton « play », la fonction « sauvegardeDonnees() » est appelée. Cette fonction permet de garder en mémoire, lors du chargement de la page, l’ancien nombre de clic sur des formes (clicForme) puisqu’il est envoyé en tant que paramètre GET. Cette valeur sera réinitialisée, seulement lorsque l’utilisateur aura validé une forme et passera donc au son suivant à l’aide de la fonction « sonSuivant() ».
Pour l’envoi des données et le lancement du son, un bouton a été créé sous forme d’image. L’appel d’une fonction JavaScript ne fonctionnant pas sur un bouton de type « submit » dans la configuration de la page, il a donc fallu créer une image à la place du bouton. Le formulaire a été gardé pour une question de mise en page, qui permet simplement d’avoir le bouton « écouter le son » et le bouton « play » côte à côte sans créer de feuille CSS.
Pour la sortie en CSV lors de la phase de test, nous avons remarqué un problème d’affichage des caractères spéciaux, mais uniquement sous Excel car Excel ne détecte pas l’encodage du fichier mais utilise sa valeur par défaut qui varie en fonction de la langue de l’utilisateur. Pour remédier à cela il y a 2 solutions possibles : soit on force Excel à utiliser de l’UTF-8 pour ouvrir le fichier (il faut alors insérer un caractère spécial appelé B UTF8 au début du fichier lors de sa génération), soit on ouvre Excel puis dans l’onglet « Données » on clique sur « Fichier Texte » et on importe notre fichier en prenant soin de bien choisir « 65001 : Unicode (UTF-8) ».
Un autre problème a été rencontré dans le fichier CSV lorsqu’il est ouvert avec Excel : lorsque l’utilisateur a cliqué uniquement sur deux formes (une forme hésitation et une forme choisie définitivement) le TimeStamp du deuxième choix est tronqué à l’affichage.
Lors de l’ouverture dans un éditeur de texte tel que SublimeText, la donnée apparait bien correctement et non tronquée.
Les différents traitements tels que l’initialisation des variables, le choix des formes à afficher, sont faits sur la page consigne.php qui est affichée juste avant que l’utilisateur fasse l’exemple.
De plus, il a fallu contourner le fait que le JavaScript ne prenne pas en compte des variables qui fonctionnent sur le même type que les variables de session en PHP. C’est pourquoi nous avons dû créer des fonctions qui seront appelées par le PHP à chaque changement de situation auquel on devra réinitialiser les variables de nombre de clics sur les formes, et la variable qui contient les formes respectives sur lesquelles l’utilisateur a cliqué. Pour garder en mémoire ces variables, le choix a été fait de garder le contenu de ces variables par le biais de la barre d’adresse. En envoyant les valeurs par GET, on peut ensuite les récupérer pour pouvoir les modifier. Cependant, JavaScript n’a pas de fonction pré implémentée permettant de récupérer des paramètres d’une URL. Il a donc été nécessaire de parser l’URL pour récupérer le paramètre voulu. Une fonction « $_GET(param) » permet d’effectuer ces différentes actions, et tout comme PHP de renvoyer un tableau dans lequel se trouvent les différentes valeurs envoyées en GET.
En ce qui concerne les différentes formes cliquées entre la première écoute et le choix définitif de l’utilisateur, le choix a été fait de concaténer la taille (petit ou grand) à la fin du nom de l’image. Lorsque l’utilisateur a fini le test, nous obtenons donc une chaine de caractères contenue dans « chaine Forme Clic » du type :piqueBlanc. pnggrand,piqueRond Rouge.pnggrand,pique Rouge. pnggrand
Le .png n’apportant aucune information, juste avant l’écriture des résultats dans le CSV dans la page questionnaire.php, la chaine est splittée en fonction du « .png ». Nous obtenons alors un tableau contenant tous les éléments de la chaine splittée. Il faut alors  parcourir le tableau pour concaténer tous les éléments du tableau et obtenir la même chaîne sans le « .png ».

Choix de mise en page

Pour réaliser la mise en page de cette interface, il y avait deux possibilités. Soit on réalisait un tableau HTML à l’aide des balises <tr> et <td>, soit on utilisait des <div>. La deuxième solution a été choisie dans un premier temps car elle permettait l’utilisation de Bootstrap pour la mise en page. Mais après avoir essayé de modifier cette mise en page, il s’est avéré qu’il serait bien plus simple d’utiliser le simple tableau HTML composé de balises <tr> et <td> pour différentes raisons. Il était tout d’abord plus simple de faire en sorte que l’image affichée dans une cellule du tableau soit alignée verticalement sur le bas de cette même cellule pour que lorsque l’échelle de Likert s’affiche, on puisse l’avoir collée à l’image concernée et non pas à l’image du dessous. En effet, même si avec les <div>, les <div> les plus petites ne prenaient pas la taille des <div> plus grandes sur la même ligne, celles qui étaient placées en-dessous s’affichaient alignées à celles qui étaient les plus grandes au-dessus. Dans un tableau HTML avec <tr>, il a suffi d’utiliser la propriété CSS « vertical-align » avec la valeur « bottom » pour pouvoir aligner l’image verticalement sur le bas de la cellule. Enfin, il était plus évident de rendre le tableau responsive avec un simple tableau HTML.
Pour l’affichage des formes sur l’écran de l’utilisateur, nous avons fait le choix d’avoir quatre modèles différents d’affichage des formes mélangées. Pour ceci, il a fallu faire un tableau multidimensionnel contenant les 4 différents tableaux qui comprennent les différentes formes dans l’ordre d’affichage. Pour opérer un affichage aléatoire à chaque nouvel utilisateur, nous avons fait toutes les associations possibles entre modèle de forme et modèle de son.

Analyse des résultats

L’analyse des résultats est une étape nécessaire pour pouvoir tirer des conclusions du test de perception. Le fichier CSV étant composé des réponses de chaque sujet à la suite, il a été nécessaire de trier les réponses en fonction des sons et non plus en fonction des identifiants des sujets. Pour cela, il a suffi d’effectuer un tri par ordre alphabétique de la colonne contenant les sons (colonne numéro 13). Cela nous a ainsi permis d’obtenir un fichier constitué de façon à ce que les 36 réponses pour chaque son (car 36 sujets ont passé le test à ce jour) soient regroupées les unes à la suite des autres. Ce tri a été effectué avec la fonction de tri d’Excel.
Dans un second temps, un programme Perl a été réalisé qui permet de prendre en entrée ce fichier CSV de réponses global trié en fonction des sons et d’en ressortir des données facilement exploitables pour pouvoir en faire des graphiques sous Excel. A noter que la ligne de titre des colonnes a été supprimée pour que les lignes de réponses commencent à 1. Le fichier est ainsi lu ligne par ligne et splitté en fonction du séparateur du fichier CSV « ; ». A chaque fois que l’on se situe sur la première ligne d’un nouveau son, nous écrivons dans le fichier CSV de sortie le nom du son traité. Cette information est récupérée à l’aide d’un modulo. A partir de cette ligne et jusqu’à la dernière ligne de réponse d’un même son, nous allons chercher le contenu de la colonne correspondant à la forme choisie définitivement par le sujet, qui se trouve à la colonne numéro 17. Cette donnée est alors stockée dans un tableau associatif qui comptabilisera le nombre de fois où cette forme a été choisie. Lorsque l’on arrive à la dernière ligne de réponse pour un même son, ces différentes données sont alors inscrites dans le fichier CSV de sortie. Cela nouspermettra ainsi de savoir quelle est la forme la plus choisie pour un son.

Table des matières
Introduction 
1. CONTEXTE DE TRAVAIL
2. CONTEXTE DU CAHIER DES CHARGES:
3. ETAT DE L’ART
4. CAHIER DES CHARGES
Partie 1 – Réalisation du projet 
CHAPITRE 1. STRUCTURE NODEJS 
1. MODULES
2. WEBSOCKET
CHAPITRE 2. ARCHITECTURE DE L’APPLICATION
1. LA PAGE UTILISEE PAR LE MAGICIEN
2. LA PAGE DE CREATION
3. LA PAGE AFFICHEE DANS DOMUS
Partie 2 – Test de perception 
CHAPITRE 1. CHOIX DES PRIMITIVES UTILISEES
1. PRIMITIVES SONORES
2. PRIMITIVES VISUELLES
CHAPITRE 2. REALISATION DU TEST
1. DONNEES RECUPEREES ET STOCKAGE
2. CHOIX DE MISE EN PAGE
3. SECURISATION DU SERVEUR PHP
4. ANALYSE DES RESULTATS
Conclusion

Télécharger le rapport complet