Authentification dans MVCR

Licence Informatique, semestre 6

Jean-Marc LecarpentierPascal Vanier

Enseignement des technologies du Web

 

Authentification dans MVCR

Notes de cours

  • Authentification
    • Stockage des mots de passe
    • Connexion et déconnexion
    • Restriction des accès

Travail personnel

Objectifs

On continue à implémenter l'architecture du site. L'exercice de ce TP implémente l'authentification et la gestion des droits. Pas de CM cette semaine : les notes de cours ci-dessus ont été présentés à la séance 10. Les trois dernières slides des notes de cours sont notamment pertinentes pour l'implémentation de l'authentification dans MVCR.

Exercice 1 — Authentification dans MVCR #

Mise en place des comptes dans l'architecture

  1. Créer une classe Account qui représente un compte utilisateur (nom, login, mot de passe et statut). Créer une interface AccountStorage pour manipuler des comptes en BD. On ne s'occupe pas encore de création, modification et suppression ; en revanche on va avoir besoin d'une méthode checkAuth($login, $password), qui est censée renvoyer l'instance de Account correspondant au couple login-mot de passe s'il est correct, et null sinon.
  2. Créer une classe AccountStorageStub qui implémente AccountStorage avec un tableau écrit en dur.

Authentification

  1. Ajouter une méthode makeLoginFormPage à la vue. Faire le nécessaire dans le routeur pour que le site comporte une page dédiée à la connexion des internautes. Ajouter un lien vers cette page de connexion dans le menu.
  2. Implémenter la vérification de la connexion. Cela peut se faire dans le contrôleur dans un premier temps, mais une solution plus propre est de faire un AuthenticationManager séparé. (On pourra s’inspirer de la classe proposée dans le TP 10.) Si les informations sont valides, le compte correspondant est récupéré en BD, et placé dans une variable $_SESSION['user']. Le contrôleur appelle ensuite une méthode de la vue qui effectue une redirection vers la page d'accueil avec un feedback.
  3. Restreindre l'accès des internautes non connecté·e·s à seulement la page d'accueil, la page de connexion et la liste des animaux, en vérifiant la valeur de $_SESSION['user'].
  4. Implémenter la déconnexion. Ajouter un lien sur la page d'accueil pour tester. (Dans la section suivante, on gérera ça plus proprement.)

Affichage public/privé

Pour l'instant, le site s'affiche de la même façon pour tout le monde (que la personne soit connectée ou non). C'est un peu absurde, en particulier pour le menu : le lien « nouvel animal » ne concerne que les connecté·e·s, le lien « Se connecter » ne concerne que les autres, etc. On va changer ça en séparant la vue en deux versions.

  1. Créer une classe PrivateView qui hérite de View. Son constructeur prendra une instance de Account en plus des autres paramètres. Le routeur construira une instance de PrivateView plutôt que View si l'internaute est connecté·e.
  2. S'arranger pour que le menu soit différent dans PrivateView. Typiquement, l'attribut $menu dans la vue de base devrait être rempli avec une méthode getMenu, cette méthode étant redéfinie dans PrivateView. En particulier, on va afficher le lien de déconnexion à la place du lien de connexion pour les internautes connecté·e·s.
  3. Redéfinir la page d'accueil dans la vue privée pour saluer l'internaute connecté·e.

Gestion des droits sur les objets

Gérer les accès plus précisément :

  • un animal ne doit pouvoir être édité ou supprimé que par la personne qui l'a créé (cela nécessite d'ajouter des informations dans la base)
  • les admins doivent pouvoir éditer et supprimer tous les animaux.

Pour faire ce genre de chose de manière sécurisée, une solution est de déclarer dans le routeur un tableau contenant la liste des actions autorisées pour l'internaute connecté·e, et de tester si l'action demandée est dans la liste avant la gestion des actions. Autrement dit, toutes les pages sont interdites par défaut : il faudra explicitement autoriser l'accès dans chaque cas.