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 u
Trang 1278 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
Trang 2Production 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 WEBSCOPE 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
Trang 3280 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, un identifiant
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é ;
Trang 43 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 SQLComplFilms.sql
CREATE TABLE S e s s i o n W e b ( i d _ s e s s i o n VARCHAR ( 4 0 ) NOT NULL,
e m a i l VARCHAR( 6 0 ) NOT NULL,
nom VARCHAR( 3 0 ) NOT NULL,
prenom VARCHAR( 3 0 ) NOT NULL,
t e m p s _ l i m i t e DECIMAL ( 1 0 , 0 ) NOT NULL, PRIMARY KEY ( i d _ s e s s i o n ) ,
FOREIGN KEY ( e m a i l ) REFERENCES I n t e r n a u t 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
Trang 5282 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 WEBSCOPEest conçu, comme beaucoup d’autres, avec une barre de menu ó 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, sinon false 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 ó 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
p r o t e c t e d f u n c t i o n c r e e r S e s s i o n ( $ e m a i l , $ m o t _ d e _ p a s s e ,
$ i d _ s e s s i o n )
{
/ / R e c h e r c h o n s s i l ’ i n t e r n a u t e e x i s t e
$ e m a i l _ p r o p r e = $ t h i s−>bd−>prepareChaine ( $email ) ;
$ r e q u e t e = " SELECT ∗ FROM I n t e r n a u t e WHERE e m a i l = ’
$ e m a i l _ p r o p r e ’ " ;
$ r e s = $ t h i s−>bd−>execRequete ( $ r e q u e t e ) ;