TD9 – Messages Flash Une autre application des sessions

Copiez/collez dans un nouveau dossier TD9 tous les fichiers du dossier TD8.

Les messages peuvent s’afficher sur n’importe quelle page qui utilise vueGenerale.php, que nous allons mettre à jour pour afficher tous les messages existants.

Dans vueGenerale.php, rajoutez le <div> suivant juste après le <nav> dans le <header>.

<div>
    <?php
    /** @var string[][] $messagesFlash */
    foreach($messagesFlash as $type => $messagesFlashPourUnType) {
        // $type est l'une des valeurs suivantes : "success", "info", "warning", "danger"
        // $messagesFlashPourUnType est la liste des messages flash d'un type
        foreach ($messagesFlashPourUnType as $messageFlash) {
            echo <<< HTML
            <div class="alert alert-$type">
               $messageFlash
            </div>
            HTML;
        }
    }
    ?>
</div>

Prenez le temps de bien comprendre ce code.

/* Bootstrap alerts */
/* https://getbootstrap.com/docs/3.4/components/#alerts */

.alert {
    padding: 15px;
    margin-bottom: 20px;
    border: 1px solid transparent;
    border-radius: 4px;
}

.alert-success {
    color: #3c763d;
    background-color: #dff0d8;
    border-color: #d6e9c6;
}

.alert-info {
    color: #31708f;
    background-color: #d9edf7;
    border-color: #bce8f1;
}

.alert-warning {
    color: #8a6d3b;
    background-color: #fcf8e3;
    border-color: #faebcc;
}

.alert-danger {
    color: #a94442;
    background-color: #f2dede;
    border-color: #ebccd1;
}

On obtient alors par exemple un bloc de succès avec le code :

<div class="alert alert-success">...</div>

http://localhost/tds-php/TD9/web/controleurFrontal.php?messagesFlash[success][]=Hello+World

ou

http://localhost/tds-php/TD9/web/controleurFrontal.php?messagesFlash[danger][]=Message+de+danger+1&messagesFlash[danger][]=Message+de+danger+2

Remarque : les messages sont affichés sans htmlspecialchars (cf. TD5). Comme ils proviennent ici de l’URL, n’importe qui peut injecter du HTML ou du JavaScript dans la page (essayez avec messagesFlash[info][]=<h1>Hack</h1>). Cette faille disparaîtra dans la suite du TD, quand les messages flash seront écrits uniquement par le serveur.

header("Location: $url");
exit();

En effet, quand un navigateur reçoit l’en-tête de réponse Location, il effectue une redirection, c’est-à-dire qu’il lance une requête vers la nouvelle URL comme si on avait cliqué sur un lien. Enfin, exit() termine l’exécution du script courant.

Note : Le type de retour never indique une fonction qui ne retourne jamais, c.-à-d. qui appelle exit(), lève une exception, ou est une boucle infinie.

Utilisons la redirection dans un premier scénario d’erreur. Dans ControleurUtilisateur::afficherDetail, si le login ne correspond à aucun utilisateur, utilisez la redirection précédente vers l’URL de l’action afficherListe avec le message flash de type danger suivant : Login inconnu.

Aide : Par exemple, pour rediriger vers l’action bonjour du contrôleur exemple avec la donnée var=a avec un message flash de succès OK, on peut écrire :

 ControleurUtilisateur::redirigerVersURL('controleurFrontal.php?controleur=exemple&action=bonjour&var=a&messagesFlash[success][]=OK');

Dans ControleurUtilisateur::supprimer, si l’utilisateur a bien été supprimé, redirigez-le vers l’action afficherListe avec le message flash de succès L'utilisateur a bien été supprimé.

Implémentez un système de message flash en complétant le squelette suivant dans le fichier src/Lib/MessageFlash.php :

namespace App\Covoiturage\Lib;

use App\Covoiturage\Modele\HTTP\Session;

class MessageFlash
{

   // Les messages sont enregistrés en session associée à la clé suivante
   private static string $cleFlash = "_messagesFlash";

   /**
    * Renvoie le tableau à deux dimensions ne contenant aucun message.
    * Ce tableau sert de valeur initiale lorsque aucun message flash n'est
    * stocké en session, et de valeur de réinitialisation après lecture.
    * @return string[][]
    */
   private static function messagesVides(): array
   {
      return ["success" => [], "info" => [], "warning" => [], "danger" => []];
   }

   /**
    * Renvoie le tableau à deux dimensions stocké en session à la clé
    * MessageFlash::$cleFlash.
    *
    * Si cette clé n'est pas présente en session, renvoie le tableau
    * sans message donné par MessageFlash::messagesVides().
    *
    * Remarque : c'est le serveur qui écrit cette donnée en session.
    * Si elle est présente, on peut donc supposer qu'elle a le bon format.
    * @return string[][]
    */
   private static function lireSession(): array
   {
      // À compléter
      return [];
   }

   /**
    * Récupère le tableau des messages flashs grâce à MessageFlash::lireSession(),
    * puis ajoute une entrée contenant $message à la fin du sous-tableau
    * associé à la clé $type.
    * Enregistre ensuite ce tableau en session à la clé MessageFlash::$cleFlash.
    */
   public static function ajouter(string $type, string $message): void
   {
      // À compléter
      return;
   }

   /**
    * Renvoie le tableau à deux dimensions contenant tous les messages flashs,
    * rangés par type, obtenu grâce à MessageFlash::lireSession().
    *
    * Attention : la lecture doit détruire tous les messages. Avant de renvoyer
    * le tableau, il faut donc enregistrer en session, le tableau sans message 
    * donné par MessageFlash::messagesVides().
    * @return string[][]
    */
   public static function lireTousMessages(): array
   {
      // À compléter
      return [];
   }

}

Ajoutez la méthode rediriger au contrôleur générique, en copiant le code ci-dessus.

Prenez bien le temps de comprendre ce que fait cette méthode, ligne par ligne. Demandez à votre enseignant chargé de TD si vous n’êtes pas sûr de comprendre certaines parties.

Remplacez les appels à redirigerVersURL par rediriger dans les actions ControleurUtilisateur::afficherDetail et ControleurUtilisateur::supprimer.

Testez et vérifiez que tout fonctionne et que vos messages flash s’affichent toujours.

En particulier, supprimez les vues désormais inutiles comme utilisateurCree.php, utilisateurConnecte.php, utilisateurDeconnecte.php, utilisateurMisAJour.php et utilisateurSupprime.php. Faites de même pour les vues trajets et éventuellement les vues concernant les passagers si vous aviez fait certaines questions bonus.

Remplacez ces vues par des messages flash de type success dans les actions concernées.

• Par exemple, en cas de succès de création d’un utilisateur, on pourrait ajouter un message flash de succès L’utilisateur a bien été créé puis rediriger vers l’action afficherListe du contrôleur utilisateur.

• Ou bien, pour la connexion, on pourra ajouter un message flash de succès Connexion réussie puis rediriger vers l’action afficherDetail du contrôleur utilisateur en passant le login de l’utilisateur dans l’URL grâce au tableau associatif $query de la méthode rediriger.

L’action enregistrerPreference() doit maintenant rediriger vers l’action par défaut du contrôleur par défaut, que l’on obtient sans indiquer d’action ni de contrôleur dans la méthode rediriger, avec un message flash de succès La préférence de contrôleur est enregistrée.

Action afficherDetail

• s’il manque le login, redirigez vers la liste des utilisateurs avec un message flash Login manquant de type danger.

Action creerDepuisFormulaire

• s’il manque des données, redirigez vers le formulaire de création avec un message flash Données manquantes de type danger.

• si les deux champs mot de passe ne coïncident pas, redirigez vers le formulaire de création avec un message flash Mots de passe distincts de type warning.

• si le format de l’email n’est pas valide, redirigez vers le formulaire de création avec un message flash Adresse email invalide de type warning.

• si la sauvegarde échoue (par exemple parce que le login est déjà pris), redirigez vers le formulaire de création avec un message flash Échec de la sauvegarde de type warning.

• s’il manque le login, redirigez vers la liste des utilisateurs avec un message flash Login manquant de type danger.

• si l’utilisateur qui modifie le profil n’est pas l’utilisateur à qui appartient le profil ou un administrateur, redirigez vers la liste des utilisateurs avec un message flash La mise à jour n’est possible que pour l’utilisateur connecté de type danger.

• si l’utilisateur n’existe pas, redirigez vers la liste des utilisateurs avec un message flash Utilisateur inexistant de type danger.

Action mettreAJour :

• s’il manque des données, redirigez vers la liste des utilisateurs avec un message flash Données manquantes de type danger.

• si l’utilisateur n’existe pas, redirigez vers la liste des utilisateurs avec un message flash Utilisateur inexistant de type danger.

• si l’utilisateur qui modifie le profil n’est pas l’utilisateur à qui appartient le profil ou un administrateur, redirigez vers la liste des utilisateurs avec un message flash La mise à jour n’est possible que pour l’utilisateur connecté de type danger.

• si les 2 nouveaux mots de passe ne coïncident pas, redirigez vers le formulaire de mise à jour en indiquant le login dans l’URL (toujours grâce au paramètre $query de rediriger) avec un message flash Mots de passe distincts de type warning.

• si l’ancien mot de passe n’est pas correct et que l’utilisateur n’est pas administrateur, redirigez vers le formulaire de mise à jour en indiquant le login dans l’URL avec un message flash Ancien mot de passe erroné de type warning.

• si le format du nouvel email n’est pas valide, redirigez vers le formulaire de mise à jour en indiquant le login dans l’URL avec un message flash Adresse email invalide de type warning.

• s’il manque le login, redirigez vers la liste des utilisateurs avec un message flash Login manquant de type danger.

• si l’utilisateur qui supprime l’utilisateur n’est pas l’utilisateur à qui appartient le profil ou un administrateur, redirigez vers la liste des utilisateurs avec un message flash La suppression n’est possible que pour l’utilisateur connecté de type danger.

• si la suppression a échoué, par exemple parce que l’utilisateur n’existe pas, redirigez vers la liste des utilisateurs avec un message flash Utilisateur inexistant de type danger.

• si le login ou le mot de passe ne sont pas transmis, redirigez vers le formulaire de connexion avec un message flash Login et/ou mot de passe manquant de type danger.

• si l’utilisateur n’existe pas ou que le mot de passe est incorrect, redirigez vers le formulaire de connexion avec un message flash Login et/ou mot de passe incorrect de type warning.

• si l’utilisateur n’a pas validé son adresse email, redirigez vers le formulaire de connexion avec un message flash Votre adresse email n’est pas validée de type warning.

Action validerEmail :

• s’il manque le login et/ou le nonce, redirigez vers la liste des utilisateurs avec un message flash Données manquantes de type danger.

• en cas de succès de la validation de l’email, redirigez vers la page de détail de cet utilisateur (en passant son login dans l’URL grâce au paramètre $query de rediriger) avec un message flash Adresse email validée de type success.

• en cas d’échec de la validation de l’email, redirigez vers la liste des utilisateurs avec un message flash Erreur lors de la validation de type danger.

• à la création d’un trajet, si le login du conducteur ne correspond à aucun utilisateur, redirigez vers le formulaire de création avec un message flash Conducteur inconnu de type warning ;
• si vous avez codé le contrôleur passager (bonus du TD6), vérifiez la présence des paramètres et l’existence du trajet, et traitez l’échec de l’inscription (login inconnu, passager déjà inscrit).

Normalement, à ce stade, vous ne devriez plus avoir d’appel à afficherErreur dans vos contrôleurs. Nous allons donc, a priori, pouvoir supprimer cette méthode. Cependant, elle est encore utilisée à un dernier endroit : le point d’entrée de notre site, controleurFrontal.php. Nous pouvons mettre en place deux solutions :

• Soit remplacer les appels à afficherErreur dans controleurFrontal.php par un ajout de messages flash de type danger et une redirection vers le contrôleur et l’action par défaut (en appelant ControleurGenerique::rediriger sans paramètres).
  Attention : ne redirigez pas vers le contrôleur demandé (rediriger($controleur)). Par exemple, pour controleurFrontal.php?controleur=preference, l’action par défaut afficherListe n’existe pas dans ce contrôleur : la redirection tournerait en boucle.

• Soit créer une vue globale erreur.php dans le dossier src/vue puis une méthode statique afficherErreur($message) dans ControleurGenerique qui appellera cette vue en lui passant le message d’erreur (proche de ce que nous avions jusqu’ici). Il suffit alors d’utiliser ControleurGenerique::afficherErreur dans controleurFrontal.php à la place de ce qui était utilisé jusqu’ici.

Choisissez une des deux solutions et implémentez-la. Ensuite, vérifiez dans chaque contrôleur (sauf le contrôleur générique) que la méthode afficherErreur n’est plus utilisée et supprimez-la.