278 Chapitre 6. Architecture du site : le pattern MVC modèle représentant les films. Un film est modélisé comme un objet composé de lignes provenant de plusieurs tables : les données du film lui-même (table Film), le metteur en scène (table Artiste) et la liste des acteurs (table Artiste également). Tout en gardant la même interface simple que TableBD, la classe Film gère ce mapping en reconstituant la description complète d’un film comme un graphe d’objets au moment des recherches ou des mises à jour. Les nombreux commentaires placés dans le code vous permettront de comprendre l’articulation des données. Enfin, je vous rappelle que le chapitre 9 est consacré à une introduction au Zend Framework qui constitue une réalisation d’une toute autre envergure et d’une toute autre complexité que le MVC simplifié présenté ici. Production du site 7 Ce chapitre est consacré aux fonctionnalités du site WEBSCOPE. Elles sont dévelop- pées selon les principes décrits dans les chapitres précédents. Le site s’appuie sur la base de données définie au chapitre 4. Rappelons que vous pouvez, d’une part utiliser ce site sur notre serveur, d’autre part récupérer la totalité du code, le tester ou le modifier à votre convenance. Rappelons enfin que ce code est conçu comme une application PHP fonctionnant aussi bien avec MySQL que n’importe quel SGBD relationnel. Le chapitre aborde successivement quatre aspects, correspondant chacun à un contrôleur. Le premier (contrôleur Auth) est la gestion de l’authentification permettant d’iden- tifier un internaute accédant au site, avant de lui accorder des droits de consultation ou de mise à jour. Ces droits sont accordés pour une session d’une durée limitée, comme présenté déjà page 98. Cette fonctionnalité d’authentification couplée avec une gestion de sessions est commune à la plupart des sites web interactifs. Les points suivants sont plus spécifiques, au moins du point de vue applicatif, au site de filtrage coopératif W EBSCOPE. Nous décrivons tout d’abord le contrôleur Notation qui permet de rechercher des films et de leur attribuer une note, puis l’affichage des films (contrôleur Film) avec toutes leurs informations. Cet affichage comprend un forum de discussion qui permet de déposer des commentaires sur les films et de répondre aux commentaires d’autres internautes. Enfin, la dernière partie (contrôleur Recomm) est consacrée à l’algorithme de prédiction qui, étant données les notes déjà attribuées par un internaute, recherche les films les plus susceptibles de lui plaire (contrôleur Recomm). Ce chapitre est également l’occasion d’approfondir la présentation du langage SQL qui n’a été vu que superficiellement jusqu’à présent. Il existe de nombreuses améliorations possibles au code donné ci-dessous. Quelques-unes sont suggérées au passage. En règle générale, c’est un bon exercice de reprendre ces fonctionnalités et de chercher à les modifier. 280 Chapitre 7. Production du site 7.1 AUTHENTIFICATION Dans tout site web interactif, on doit pouvoir identifier les internautes avant de leur fournir un accès aux services du site. En ce qui nous concerne, nous avons besoin de savoir qui note les films pour pouvoir faire des prédictions. La procédure classique, dans ce cas, est la suivante : • lors du premier accès au site, on propose au visiteur de s’inscrire en fournissant un identifiant (pour nous ce sera l’e-mail) et un mot de passe ; • lors des accès suivants, on lui demande de s’identifier par la paire (email, mot de passe). 7.1.1 Problème et solutions Comme déjà évoqué à la fin du chapitre 1, le protocole HTTP ne conserve pas d’informations sur la communication entre un programme client et un programme serveur. Si on s’en contentait, il faudrait demander, pour chaque accès,unidentifiant et un mot de passe, ce qui est clairement inacceptable. La solution est de créer un ou plusieurs cookies pour stocker le nom et le mot de passe du côté du programme client. Rappelons (voir la fin du chapitre 1, page 17) qu’un cookie est essentiellement une donnée transmise par le programme serveur au programme client, ce dernier étant chargé de la conserver pour une durée détermi- née. Cette durée peut d’ailleurs excéder la durée d’exécution du programme client lui-même, ce qui implique que les cookies soient stockés dans un fichier texte sur la machine cliente. On peut créer des cookies à partir d’une application PHP avec la fonction SetCookie(). Il faudrait donc transmettre l’e-mail et le mot de passe après les avoir récupérés par l’intermédiaire d’un formulaire, et les relire à chaque requête d’un programme client. Ce processus est relativement sécurisé puisque seul le programme serveur qui a créé un cookie peut y accéder, ce qui garantit qu’un autre serveur ne peut pas s’emparer de ces informations. En revanche toute personne pouvant lire des fichiers sur la machine client peut alors trouver dans le fichier cookies la liste des sites visités avec le nom et le mot de passe qui permettent d’y accéder Sessions temporaires La solution la plus sécurisée (ou la moins perméable ) est une variante de la précédente qui fait appel au système de sessions web dont les principes ont été exposés chapitre 2, page 98. Cette variante permet de transmettre le moins d’informations possible au programme client. Elle repose sur l’utilisation d’une base de données du côté serveur et peut être décrite par les étapes suivantes : 1. quand un utilisateur fournit un e-mail et un mot de passe, on compare ces informations à celles stockées dans la base, soit dans notre cas dans la table Internaute ; 2. si le nom et le mot de passe sont corrects, on crée une ligne dans une nouvelle table SessionWeb, avec un identifiant de session et une durée de validité ; 7.1 Authentification 281 3. on transmet au client un cookie contenant uniquement l’identifiant de session ; 4. si l’identification est incorrecte, on refuse d’insérer une ligne dans SessionWeb, et on affiche un message – poli – en informant l’internaute ; 5. à chaque accès du même programme client par la suite, on récupère l’identifiant de session dans le cookie, vérifie qu’il correspond à une session toujours valide, et on connaîtra du même coup l’identité de l’internaute qui utilise le site. Ce processus est un peu plus compliqué, mais il évite de faire voyager sur l’Internet une information sensible comme le mot de passe. Dans le pire des cas, l’identifiant d’une session sera intercepté, avec des conséquences limitées puisqu’il n’a qu’une validité temporaire. 7.1.2 Contrôleur d’authentification et de gestion des sessions Nous allons ajouter au schéma de la base Films une table SessionWeb dont voici la description. Comme quelques autres, la commande de création de cette table se trouve dans le script SQL ComplFilms.sql. CREATE TABLE SessionWeb (id_session VARCHAR (40) NOT NULL, email VARCHAR(60) NOT NULL, nom VARCHAR(30) NOT NULL, prenom VARCHAR(30) NOT NULL, temps_limite DECIMAL (10,0) NOT NULL, PRIMARY KEY (id_session) , FOREIGN KEY ( email ) REFERENCES In t er n a ut e ); Chaque ligne insérée dans cette table signifie que pour la session id_session, l’internaute identifié par email à un droit d’accès au site jusqu’à temps_limite.Ce dernier attribut est destiné à contenir une date et heure représentées par le nombre de secondes écoulées depuis le premier janvier 1970 (dit « temps UNIX »). Il existe des types spécialisés sous MySQL pour gérer les dates et les horaires, mais cette représentation sous forme d’un entier suffit à nos besoins. Elle offre d’ailleurs le grand avantage d’être comprise aussi bien par MySQL que par PHP, ce qui facilite beaucoup les traitements de dates. Le nom et le prénom de l’internaute ne sont pas indispensables. On pourrait les trouver dans la table Internaute en utilisant l’e-mail. En les copiant dans SessionWeb chaque fois qu’une session est ouverte, on évite d’avoir à faire une requête SQL supplémentaire. La duplication d’information est sans impact désagréable ici, puisque les lignes de SessionWeb n’existent que temporairement. D’une manière générale cette table, ainsi que d’autres éventuellement créées et référençant l’identifiant de session, peut servir de stockage temporaire pour des données provenant de l’utilisa- teur pendant la session, comme par exemple le « panier » des commandes à effectuer dans un site de commerce électronique. 282 Chapitre 7. Production du site Fonctionnalités de gestion des sessions Les fonctionnalités relatives aux sessions sont placées d’une part dans la super-classe Controleur, ce qui permet d’en faire hériter tous les contrôleurs du site, d’autre part dans le contrôleur Auth qui se charge de gérer les actions de connexion (login) et déconnexion (logout). Le site W EBSCOPE est conçu, comme beaucoup d’autres, avec une barre de menu où figure un formulaire de saisie du login et du mot de passe. Quand on valide ce formulaire, on est redirigé vers le contrôleur Auth qui se charge alors d’ouvrir une session si les informations fournies sont correctes. Une fois qu’une internaute a ouvert une session, le formulaire de connexion dans la barre de menu est remplacé par un lien permettant de se déconnecter. La gestion de session s’appuie sur les fonctions PHP, qui donnent automatique- ment un identifiant de session (voir page 98). Rappelons que l’identifiant de la session est transmis du programme serveur au programme client, et réciproquement, tout au long de la durée de la session qui est, par défaut, définie par la durée d’exécution du programme client. La propagation de l’identifiant de session – dont le nom par défaut est PHPSESSID, ce qui peut se changer dans le fichier de configuration php.ini – repose sur les cookies quand c’est possible. Toutes les autres informations associées à une session doivent être stockées dans la base MySQL pour éviter de recourir à un fichier temporaire. On s’assure ainsi d’un maximum de confidentialité. Les utilitaires de la classe Controleur Les méthodes suivantes de gestion des sessions se trouvent dans la classe Controleur. La première prend en argument l’e-mail et le mot de passe et vérifie que ces informations correspondent bien à un utilisateur du site. Si c’est le cas elle renvoie true,sinonfalse. La vérification procède en deux étapes. On recherche d’abord les coordonnées de l’internaute dans la table Internaute avec la variable $email, puis on compare les mots de passe. Si tout va bien, on crée la session dans la table. Le mot de passe stocké dans Internaute est crypté avec la fonction md5() qui renvoie une chaîne de 32 caractères (voir le script d’insertion d’un internaute à la fin du chapitre précédent). Il n’y a pas d’algorithme de décryptage de cette chaîne, ce qui garantit que même dans le cas où une personne lirait la table contenant les mots de passe, elle ne pourrait pas sans y consacrer beaucoup d’efforts les obtenir en clair. On doit donc comparer l’attribut mot_de_passe de la table avec le cryptage de la variable PHP $mot_de_passe. protected function creerSession ($email , $mot_de_passe , $id_session) { // Recherchons si l ’internaute existe $email_propre = $this−>bd−>prepareChaine($email); $ r e quete = "SELECT ∗ FROM Internaute WHERE email=’ $email_propre ’" ; $res = $this−>bd−>execRequete ($requete) ; . visiteur de s’inscrire en fournissant un identifiant (pour nous ce sera l’e-mail) et un mot de passe ; • lors des accès suivants, on lui demande de s’identifier par la paire (email, mot de passe). 7.1.1. leurs informations. Cet affichage comprend un forum de discussion qui permet de déposer des commentaires sur les films et de répondre aux commentaires d’autres internautes. Enfin, la dernière partie. (contrôleur Auth) est la gestion de l’authentification permettant d’iden- tifier un internaute accédant au site, avant de lui accorder des droits de consultation ou de mise à jour. Ces droits sont