TP3 — Restructuration de Dex et authentification

L’outil Dex construit au TP2 fonctionne, mais présente de sérieux défauts affectant la fiabilité, la sécurité et la maintenabilité du code. Jusqu’à présent n’importe qui peut saisir le nom d’un autre étudiant pour modifier ses disponibilités. Malgré l’introduction d’une classe et l’utilisation de fragments pour le layout, les pages demeurent chargées en logique et responsabilités diverses.

Ce dernier travail vise à corriger ces défauts. Vous réorganisez Dex en encapsulant la logique dans des classes dédiées, et vous remplacez le champ « nom » par une véritable authentification avec des comptes, des rôles et des pages protégées.

Ce TP est une reprise, pas un projet neuf. Les fonctionnalités visibles restent essentiellement les mêmes qu’au TP2 ; ce qui change, c’est l’organisation du code et la façon dont l’utilisateur est identifié. L’évaluation porte donc surtout sur la structure et sur l’authentification

Point de départ

Vous partez de votre propre TP2. Les données de la plateforme (le cours et ses travaux) et la grille de créneaux restent celles du TP2, toujours servies par la classe qui isole leur source.

↩ Reprendre son code

Reprendre un projet existant est le quotidien du métier. L’exercice consiste à déplacer des responsabilités sans casser ce qui marchait : avancez par étapes et vérifiez le fonctionnement après chacune.

Partie 1 : améliorer la maintenabilité du code

Une page doit se lire d’un coup d’œil. Pour cela, elle ne fait plus le travail elle-même : elle le confie à des classes de service qui encapsulent la logique.

Concrètement, chaque page se limite à quatre gestes : protéger l’accès, lire les paramètres reçus, appeler un service pour obtenir ou enregistrer des données, puis afficher le résultat.

Avant et après

Une page qui fait tout elle-même :

<?php
// travail.php (tout mélangé)
$pdo = new PDO('mysql:host=localhost;dbname=dex;charset=utf8mb4', 'root', '');
$id = $_GET['travail'] ?? '';

$requete = $pdo->prepare('SELECT etudiant, creneau FROM disponibilites WHERE travail = :t');
$requete->execute(['t' => $id]);
$lignes = $requete->fetchAll(PDO::FETCH_ASSOC);

// ... puis des dizaines de lignes qui regroupent, comptent et affichent

La même page, une fois la logique déplacée :

travail.php

<?php
session_start();
require 'config/connexion.php';   // fournit $pdo
require 'service/Coordination.php';

exigerConnexion();

$id = $_GET['travail'] ?? '';
$coordination = new Coordination($pdo, $id);

$parCreneau = $coordination->disponibilitesParCreneau();
$meilleur = $coordination->meilleurCreneau();

// ... l'affichage, à partir de données déjà prêtes

Ce que vous devez respecter :

• aucune requête SQL directement dans une page : toutes les requêtes vivent dans les classes ;
• une page ne contient ni calcul ni règle du domaine : elle peut contrôler le déroulement de la requête, mais les calculs et règles propres au fonctionnement de Dex appartiennent aux services ;
• les classes ne produisent aucun HTML : elles retournent des données, la page les affiche ;
• chaque classe reçoit sa connexion par le constructeur, garde ses attributs privés et n’expose que des méthodes claires.

Vous aurez au minimum ces classes, à ranger dans un dossier service/ (ou modeles/, à votre choix, pourvu que ce soit constant) :

Classe	Responsabilité
Plateforme	Isole la source des travaux du cours (déjà écrite au TP2).
Coordination	Disponibilités d’un travail : enregistrement, agrégation, meilleur créneau.
Auth	Inscription, connexion, déconnexion.
SessionUtilisateur	État de la session : personne connectée et rôle.

Partie 2 : authentification

Le champ « nom » disparaît du formulaire de disponibilités. L’étudiant s’identifie une fois, et Dex sait ensuite qui il est.

Vous devez fournir :

• une page d’inscription : nom, courriel, mot de passe et confirmation, avec validation côté serveur ;
• une page de connexion et une déconnexion ;
• le hachage des mots de passe avec password_hash, et leur vérification avec password_verify ;
• l’identité conservée en session, avec renouvellement de l’identifiant de session à la connexion ;
• l’affichage du nom de la personne connectée dans l’en-tête, avec un lien de déconnexion.

Rappels de sécurité

Un mot de passe ne se conserve jamais en clair, et ne se réaffiche jamais dans un formulaire après une erreur. En cas d’échec de connexion, donnez le même message quel que soit le motif, pour ne pas révéler quels comptes existent. Le courriel porte une contrainte UNIQUE, et les mots de passe demandent une longueur minimale que vous fixez.

Partie 3 : rôles et protection des routes

Deux rôles suffisent : etudiant et enseignant.

Un étudiant consulte les travaux et enregistre ses propres disponibilités. Ses réponses sont associées à son compte, et non à un nom saisi librement : il ne peut donc modifier que les siennes.

Un enseignant voit en plus une page d’administration qui liste, pour chaque travail, l’ensemble des réponses, et qui permet de fermer un travail. Lorsqu’un travail est fermé, il ne devrait plus être accessible aux étudiants.

Les règles d’accès à respecter :

• les pages de coordination exigent d’être connecté ; sinon, redirection vers la connexion ;
• la page d’administration exige le rôle enseignant ; une personne connectée sans ce rôle reçoit un 403 ;
• le lien vers l’administration ne s’affiche que pour un enseignant, sans que cet affichage tienne lieu de protection ;
• une personne déjà connectée qui ouvre la page de connexion est redirigée vers l’accueil. Regroupez ces vérifications dans un fichier commun (includes/protection.php), avec exigerConnexion() et exigerRole(...), appelé au tout début de chaque page protégée, avant la moindre sortie.

↩ Masquer n'est pas protéger

Cacher un lien améliore l’expérience, mais l’adresse reste accessible. Chaque page protégée vérifie donc le droit côté serveur, avant toute sortie.

La base de données

La base dex existe déjà. Votre script init.php, exécuté une fois, crée les tables nécessaires : celle des disponibilités du TP2, et celle des comptes.

La table des disponibilités doit maintenant référencer l’identifiant de l’utilisateur plutôt qu’un nom saisi. Un étudiant ne peut pas apparaître deux fois pour le même créneau d’un même travail.

Schéma cible

CREATE TABLE IF NOT EXISTS utilisateurs (
    id        INT AUTO_INCREMENT PRIMARY KEY,
    nom       VARCHAR(100) NOT NULL,
    courriel  VARCHAR(150) NOT NULL UNIQUE,
    empreinte VARCHAR(255) NOT NULL,
    role      VARCHAR(20)  NOT NULL DEFAULT 'etudiant',
    cree_le   TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE IF NOT EXISTS disponibilites (
    id             INT AUTO_INCREMENT PRIMARY KEY,
    travail        VARCHAR(50) NOT NULL,
    utilisateur_id INT NOT NULL,
    creneau        VARCHAR(50) NOT NULL,
    UNIQUE (travail, utilisateur_id, creneau),
    FOREIGN KEY (utilisateur_id) REFERENCES utilisateurs(id)
);

Prévoyez dans init.php la création d’un compte enseignant de départ, pour que le correcteur puisse essayer la page d’administration. Indiquez ses identifiants dans le README.

L’inscription publique crée uniquement des comptes étudiants. Il ne doit pas être possible de choisir son rôle dans le formulaire d’inscription.

Contraintes techniques

• Classes de service : aucune requête SQL ni règle du domaine dans les pages, aucun HTML dans les classes.
• Orienté objet : attributs privés, méthodes publiques, connexion reçue par le constructeur.
• Authentification : mots de passe hachés, identité en session, identifiant de session renouvelé à la connexion.
• Contrôle d’accès : vérification du droit au début de chaque page protégée, avant toute sortie.
• Sécurité générale : requêtes préparées partout, échappement systématique des sorties.
• init.php crée les tables dans la base dex et peut être relancé sans erreur.

Livrables

1. Une archive du projet, prête à déposer dans htdocs, avec vos dossiers service, config, includes et data.
2. Le script init.php créant les tables dans la base dex, avec le compte enseignant de départ.
3. Un README indiquant la mise en place (démarrer MySQL, exécuter init.php, ouvrir la page) et les identifiants du compte enseignant.