TD2 – Découverte du framework Symfony 2/2 Gestion des utilisateurs et finitions

Introduction

La seconde partie de la découverte de ce framework va se concentrer sur la gestion de nos utilisateurs. Comme c’est un aspect assez courant sur les applications web, Symfony possède bien sûr divers outils et processus permettant de mettre en place rapidement et facilement un système de gestion pour nos utilisateurs.

Enfin, dans une seconde partie, nous effectuerons quelques finitions sur le site comme ajouter des auteurs pour les publications et des pages personnelles pour les utilisateurs. Nous verrons aussi comment inclure d’autres templates dans un template Twig et enfin, nous personnaliserons nos pages d’erreur.

On rappelle que les commandes doivent être exécutées à l’intérieur de votre conteneur Docker.

Barre de débogage

Vous avez sans doute remarqué une barre d’outil s’affichant sur chaque page de votre application (si elle ne s’affiche pas, il faut cliquer sur le logo Symfony, en bas à droite). Cette barre s’affiche car nous sommes dans un environnement de développement (nous en reparlerons plus tard). Cette barre est très utile car elle nous fournit beaucoup d’informations :

• Temps d’exécution de la requête.
• Trace : on peut mesurer le temps passé dans chaque fichier, dans chaque fonction, dans la base de données.
• Requêtes SQL exécutées : code, temps d’exécution, nombre de requêtes
• Les données de l’utilisateur connecté.
• Les erreurs, les warnings…
• Code de réponse HTTP.

Bref, cet outil nous permet de connaître en détail l’état de notre application. Prenez le temps de l’explorer !

Les utilisateurs

Il est temps d’ajouter des utilisateurs à notre site. Avec un framework, cette étape est généralement assez simplifiée et partiellement automatisée.

Création de l’entité

Dans Symfony, il existe une commande interactive pour initier un système de gestion d’utilisateurs qui va générer la base des classes dont nous aurons besoin et va également configurer différentes choses, comme l’algorithme de hachage des mots de passe.

Cette commande se nomme make:user :

php bin/console make:user

Une fois exécutée, elle va vous demander :

• Le nom de l’entité qui jouera le rôle d’utilisateur.

• Si les informations de l’utilisateur doivent être stockées dans la base de données (login, mot de passe haché, etc…).

• Le nom de la propriété (unique) identifiant de l’utilisateur, c’est-à-dire, avec laquelle il se connectera (quelque chose supposé unique par utilisateur, par exemple, son login ou bien son adresse email…)

• Si les mots de passe doivent être hachés et vérifiés (a priori, on répond oui sauf si on a un autre système que Symfony qui gère cela).

Une fois complétée, la commande va générer une classe pour l’entité et une autre pour son repository puis va mettre à jour le fichier config/packages/security.yaml.

L’entité générée est vraiment basique et contient le strict nécessaire (id, propriété unique pour la connexion, mot de passe haché et rôles) mais il est tout à fait possible de la compléter en utilisant la commande make:entity.

À ce stade, tout est prêt pour gérer nos utilisateurs. Il n’y a plus qu’à gérer la phase d’inscription et de connexion. Mais revenons d’abord sur certains éléments importants qui ont été générés.

Au niveau de la classe Utilisateur :

• La propriété password représente le mot de passe haché (on ne stocke jamais le mot de passe en clair ici).

• La propriété roles représente une liste de rôles de l’utilisateur. Les rôles sont un système permettant d’accorder des privilèges à certains utilisateurs. On peut limiter l’accès à des routes à certains rôles, ou bien vérifier le rôle d’un utilisateur dans un template Twig. Si vous jetez un œil à la méthode getRoles, vous remarquerez que par défaut, un utilisateur a le rôle ROLE_USER. C’est le rôle basique d’un utilisateur connecté. Dans la base de données, cette valeur est stockée comme un string et décodée puis transformée en tableau par Symfony.

• La méthode eraseCredentials permet d’effacer de la mémoire de Symfony des données sensibles, éventuellement stockées dans la classe de l’utilisateur, temporairement (comme le mot de passe en clair, pour la connexion). Dans notre cas, nous ne nous en servirons pas. Vous noterez d’ailleurs que cette méthode est dépréciée et va être supprimée dans la prochaine version de Symfony.

• La classe implémente UserInterface qui est demandée comme paramètre de nombreux services (comme pour le hachage du mot de passe). Notre classe Utilisateur sera donc compatible.

Au niveau du fichier security.yaml :

• La zone app_user_provider permet d’informer Symfony quelle est l’entité qui représente nos utilisateurs ainsi que la propriété utilisée comme identifiant de connexion.

• Un peu plus bas, password_hashers permet de sélectionner l’algorithme de hachage des mots de passe. Depuis les dernières versions de Symfony, on peut utiliser la valeur auto (comme c’est le cas ici) qui permet de sélectionner le meilleur algorithme de hachage disponible. Cela permet aux mots de passe d’être le plus sécurisé possible. De plus, si cet algorithme vient à changer (par exemple, un meilleur algorithme est publié dans le futur), Symfony procède à la migration des mots de passe. La prochaine fois qu’ils se connecteront, les utilisateurs dont le mot de passe utilise encore l’ancien algorithme de hachage déclencheront automatiquement la migration de leur mot de passe qui sera re-haché avec le nouvel algorithme puis stocké, et tout cela de manière invisible. Ainsi, avec ce paramètre, le développeur n’a pas (trop) à se soucier d’être à jour niveau sécurité des mots de passe. Une partie du code de ce système se trouve dans la classe Repository/UtilisateurRepository au niveau de la méthode upgradePassword (vous pouvez y jeter un œil). Les algorithmes de hachage contiennent un système de salt, comme vous l’avez vu l’année dernière.

Formulaire d’inscription

Création du formulaire

Nous allons maintenant mettre en place un formulaire d’inscription pour nos utilisateurs !

À la différence du formulaire que nous avons créé pour les publications, celui-ci contiendra deux champs qui ne seront pas liés directement à la classe Utilisateur :

• plainPassword : il s’agit du mot de passe en clair transmis via le formulaire, qui diffère de l’attribut password qui lui représente le mot de passe haché et ne doit justement pas faire partie du formulaire ! Cela signifie que pour les assertions concernant plainPassword, il faudra le faire au niveau de la classe du formulaire, et non pas au niveau de l’entité Utilisateur.

• fichierPhotoProfil : il s’agit du fichier contenant la photo de profil de l’utilisateur. Cela est différent de nomPhotoProfil qui ne doit pas faire partie du formulaire et qui stocke seulement le nom de la photo de profil (pour l’afficher plus tard).

Vous aurez aussi besoin de nouvelles assertions :

• #[Assert\Email()] : vérifie que la chaîne de caractères est une adresse email valide (bien formée).

• #[Assert\File(maxSize : ..., extensions : [...])] : vérifie que le fichier envoyé ne dépasse pas une certaine taille et possède une des extensions autorisées (par exemple, “pdf”). Pour exprimer une taille en mégaoctets, on utilise M.

  Exemple d’une assertion File qui n’accepte que les fichiers de type mp3, wav ou ogg de 2Mo maximum :

    #[Assert\File(maxSize: '2M', extensions: ['mp3', 'wav', 'ogg'])]
  

• #[Assert\Regex(pattern: ...)] : que nous avions brièvement présenté plus tôt. Le paramètre pattern définit l’expression régulière que la chaîne de caractères doit respecter.

Pour rappel, pour ajouter un champ qui ne fait pas partie de l’entité (et lui ajouter des assertions) on le configure ainsi dans la classe du formulaire :

$builder
    //Champ qui n'est pas lié à l'entité: "mapped => false"
    ->add('monChamp', TextType::class, [
        "mapped" => false,
        //Les assertions
        "constraints" => [
            new NotBlank(),
            new Length(...)
        ],
        "attr" => [
            //Attributs HTML éventuels
        ],
        "label" => "..." //Titre du label associé au champ...
    ])
;

L’exemple d’assertion File donné plus tôt se transformerait ainsi dans le tableau du champ constraints :

new File(maxSize: '2M', extensions: ['mp3', 'wav', 'ogg'])

Vous l’aurez remarqué, nous utilisons la syntaxe des arguments nommés que nous avions évoqués lors du premier TD lors de l’introduction des attributs.

Ensuite, au niveau de la classe Utilisateur, nous pouvons utiliser un attribut

#[UniqueEntity('propriete')]

Cet attribut se place juste au-dessus du nom de la classe et permet de signifier à l’application qu’une valeur d’une propriété de la classe est unique (pas de doublons entre les utilisateurs pour cet attribut, comme le “unique” en base de données). Cela peut paraître redondant avec l’attribut ORM\UniqueConstraint lié à la base de données, mais cela permet de détecter cette erreur plus tôt, au niveau de l’application, et ainsi de la gérer par nous-même plutôt qu’obtenir une page d’erreur liée à la base de données que l’utilisateur n’est pas censé voir.

Par exemple :

#[UniqueEntity('champ1', message: "Cette valeur est déjà prise!")]
#[UniqueEntity('champ3')]
#[ORM\UniqueConstraint(name: 'UNIQ_IDENTIFIER_CHAMP_1', fields: ['champ1'])]
#[ORM\UniqueConstraint(name: 'UNIQ_IDENTIFIER_CHAMP_3', fields: ['champ3'])]
class Exemple {

    #[ORM\Column]
    private ?string $champ1 = null;

    #[ORM\Column]
    private ?string $champ2 = null;

    #[ORM\Column]
    private ?string $champ3 = null;

}

Pour bien que vous compreniez la différence, l’attribut [ORM\UniqueConstraint(...)] va créer une contrainte UNIQUE INDEX au niveau de la base de données tandis que #[UniqueEntity] est similaire aux autres assertions et est vérifié lors de l’appel à la méthode isValid du formulaire. Avec #[UniqueEntity], la vérification est faite avant toute tentative d’enregistrement en base de données et on est ainsi sûr de ne pas exécuter une requête d’insertion qui produira une erreur (pour cause de doublons).

Concernant notre formulaire, contrairement à celui de la page principale, celui-ci va contenir des balises <label>. Pour rappel, une balise <label> est censée afficher le “nom” d’un champ. Quand on clique sur le label, le “focus” (curseur) est déplacé dans l’input visé à condition d’avoir spécifié l’id de l’input dans l’attribut for.

Avec Symfony, on peut générer le <label> lié à un champ avec {{ form_label(form.champ) }} à condition que le champ label soit spécifié dans les options du champ. Cela est pratique dans le cas où nous n’avons pas besoin d’attribuer un id spécifique pour notre champ généré avec form_widget. Symfony le génèrera automatiquement et le label pointera automatiquement vers le bon id du champ visé.

Enfin, il existe une fonction utile qui permet de générer tout ce qui est relatif à un champ : l’affichage des erreurs éventuelles, le label et le champ. Pour cela, on utilise : {{ form_row(form.champ) }}. On l’utilisera quand il n’y aura aucun code HTML intermédiaire à placer entre les différentes zones du champ.

Traitement du formulaire d’inscription - Créer un service dédié

Maintenant que nous pouvons afficher notre formulaire d’inscription, il faut pouvoir le traiter ! Mais ce n’est pas aussi simple que pour les publications, car :

• Il faut hacher le mot de passe.

• Il faut sauvegarder la photo de profil (s’il y en a une) et enregistrer le nom de la photo dans les données de l’utilisateur. Il faut faire en sorte que le nom de cette image soit unique.

Cela peut représenter un volume important de code (notamment en cas d’évolution de l’application). De manière générale, Symfony conseille de garder les actions des contrôleurs le plus léger possible et de déléguer le gros de la logique métier à des services dédiés. Nous utilisons déjà plusieurs services que nous injectons dans nos actions de contrôleurs (repositories, entity manager…) mais jusqu’ici, nous n’en avons pas créé.

Pour gérer ces deux aspects, nous nous proposons de créer un service, afin de ne pas surcharger le contrôleur (et de toute façon, ce n’est pas vraiment son rôle de faire ces étapes, normalement…). Nous pourrions aussi réutiliser ce service en cas de mise à jour d’un utilisateur, par exemple.

Pour créer un service, il suffit de créer une classe dans src/Service (par convention). Nous pourrons ensuite l’injecter dans une des méthodes du contrôleur comme nous le faisons pour les autres services. Il est d’ailleurs tout à fait possible d’injecter et d’utiliser d’autres services dans notre service (par exemple, nous allons avoir besoin d’accéder à la structure de données contenant les messages flash).

Par exemple, imaginons un service qui utilisera le service EntityManagerInterface et ExempleRepository. Je peux le créer simplement ainsi :

#src/Service/ExempleService.php

class ExempleService {

    public function __construct(
        private EntityManagerInterface $entityManager,
        private ExempleRepository $exempleRepository
    ) {}

    public function maFonction() : void {
        $ex = $this->exempleRepository->findAll();
        $this->entityManager->persist(...)
    }
}

La syntaxe avec private utilisée pour définir ce constructeur ne doit pas vous être inconnue. Pour rappel, avec cette syntaxe, on signifie qu’on souhaite enregistrer directement les paramètres comme attributs de la classe (en précisant, au passage, leur visibilité). Ainsi, il n’y a pas de code basique à écrire pour déclarer manuellement ces attributs et les affecter dans le constructeur. Le corps du constructeur peut rester vide. En fait, on peut voir cela comme une version compacte entre la déclaration et l’affectation d’un attribut de la classe.

Ainsi, si j’ai une classe avec le constructeur suivant :

class Exemple {

    public function __construct(
        private string $attr
    ) {}
}

J’ai accès à un attribut $this->attr dans ma classe (qui sera affecté lors de la construction de l’objet). On peut bien entendu mettre d’autres niveaux de visibilité, comme public ou bien protected.

Concernant le service, une fois votre classe construite, vous pouvez l’injecter où vous le souhaitez (dans un contrôleur, ou bien dans un autre service) et vous en servir :

#[Route('/exemple', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(ExempleService $exempleService): Response
{
    $exempleService->maFonction();
}

Dans notre nouveau service, nous allons utiliser certaines fonctions de l’objet de type File pour nous permettre de facilement déplacer le fichier uploadé par l’utilisateur dans notre système :

// $fichier est le fichier uploadé
// $destination est le dossier vers lequel le fichier sera déplacé
do {
    $fileName = bin2hex(random_bytes(16)) . '.' . $fichier->guessExtension();
} while(file_exists($destination.'/'.$fileName));
$fichier->move($destination, $fileName);

L’utilisation de bin2hex(random_bytes(16)) permet de générer un identifiant (chaîne de caractère) aléatoire. La méthode vérifie l’unicité du fichier par une boucle (même si des collisions sont extrêmement peu probables). Ainsi, on devrait obtenir un nom de fichier unique, pour l’image de profil de l’utilisateur. La méthode guessExtension permet d’obtenir l’extension du fichier (png, jpg…). Enfin, move déplace le fichier vers un dossier de destination.

Ensuite, le service UserPasswordHasherInterface permet de hacher un mot de passe, en utilisant l’algorithme configuré dans security.yaml (dans notre cas auto, donc, le meilleur algorithme de hachage disponible).

// $this->passwordHasher est de type UserPasswordHasherInterface
// $utilisateur est de type UserInterface (classe implémentée par notre entité Utilisateur)
$hashed = $this->passwordHasher->hashPassword($utilisateur, $plainPassword);
$utilisateur->setPassword($hashed);

Concernant le dossier de destination de l’image, c’est aussi un paramètre que nous allons définir hors de notre classe et qui pourra être injecté automatiquement. La syntaxe diffère un peu dans ce cas.

Tout d’abord, il faut se rendre dans config/services.yaml et définir le paramètre souhaité dans la section parameters :

parameters:
    exemple_param: 'coucou!'

Puis, quand on souhaite l’injecter dans notre service, comme pour les autres injections, cela se passe dans le constructeur, mais cette fois, en utilisant l’attribut #[Autowire('%nom_param%')]. Par exemple :

class ExempleService {
    // Les `%` autour du nom du paramètre sont importants!
    public function __construct(
        #[Autowire('%exemple_param%')] private string $exempleParam,
        private AutreServiceInterface $autreService
    ) {}
}

Enfin, dans le contrôleur, vous aurez besoin d’aller chercher les champs plainPassword et fichierPhotoProfil dans l’objet du formulaire, pour les transmettre à votre service. Pour cela, vous pouvez utiliser la méthode getData comme dans l’exemple qui suit :

$valeurChamp = $form->get("monChamp")->getData();

Traitement du formulaire - Interfaçage du service

Comme vous l’aurez peut-être constaté, certains services comme EntityManagerInterface s’utilisent au travers d’une interface, et non pas d’une classe concrète. Pour permettre une meilleure modularité et substitutions des services de votre application (si vous décidez de changer la classe qui assure tel ou tel service), il est plus judicieux de définir vos services en les accompagnant d’une interface puis d’injecter et utiliser l’interface (dans les contrôleurs et autres) plutôt que la classe concrète.

Dans ce cas, il faut éditer le fichier config/services.yaml afin de préciser quelle est la classe concrète actuellement liée à cette interface. Ce fichier permet de configurer différents aspects des services de notre application (par exemple, quand on a besoin d’injecter des paramètres de notre application dans certains services…).

Imaginons que je crée une interface ExempleServiceInterface pour mon service défini dans un exemple précédent :

#src/Service/ExempleServiceInterface.php
interface ExempleServiceInterface {
    public function maFonction() : void;
} 

#src/Service/ExempleServiceA.php
class ExempleServiceA implements ExempleServiceInterface {
    ...
}

S’il n’y a qu’une seule classe qui implémente l’interface en question, Symfony va la trouver automatiquement et faire le lien.

Ainsi, quand je veux injecter ce service, je peux maintenant utiliser son interface (ExempleA sera alors utilisé) :

 #[Route('/exemple', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(ExempleServiceInterface $exempleService): Response
{
    $exempleService->maFonction();
}

Cependant, si deux classes (ou plus) implémentent la même interface (ce qui peut arriver : par exemple, une classe gérant la connexion à une base de données MySQL contre une classe gérant la connexion à une base de données Oracle), Symfony ne saura donc pas laquelle choisir.

Par exemple, si j’ai aussi :

#src/Service/ExempleServiceB.php
class ExempleServiceB implements ExempleServiceInterface {
    ...
}

Dans ce cas, il faut éditer le fichier config/services.yaml ainsi, en précisant le service qu’on souhaite associer à l’interface :

#Dans config/services.yaml
parameters:
    ...
services:
    #Je crée le service abstrait ExempleServiceInterface qui se réfère au service concret ExempleServiceB
    App\Service\ExempleServiceInterface: '@App\Service\ExempleServiceB'
    

Si jamais je souhaite changer de classe concrète, j’ai juste à changer le fichier services.yaml. Il n’y aura pas de changements à faire dans les classes qui utilisaient mon service jusqu’à présent.

Il peut être intéressant de créer une interface pour son service, même si on ne prévoit pas immédiatement d’avoir plusieurs classes concrètes différentes pour ce service. C’est une bonne pratique car on injectera alors systématiquement le service via l’interface, dans les contrôleurs, dans les autres services. Si jamais on vient finalement à ajouter une autre classe concrète implémentant la même interface (variante de ce service), il suffira alors d’éditer services.yaml sans toucher au reste du code si on souhaite en changer.

Connexion et déconnexion

Formulaire de connexion

Concernant la connexion, nous n’aurons pas à créer de classe pour le formulaire. En fait, il y a juste besoin de créer un formulaire HTML classique en précisant des valeurs précises pour les champs correspondants au login et au mot de passe. Aussi, il n’y aura pas besoin de gérer explicitement le traitement du formulaire, Symfony se charge de vérifier le mot de passe et de récupérer les informations sur l’utilisateur.

Tout d’abord, on commence par créer une route, accès en GET et en POST :

#[Route('/exempleConnexion', name: 'exempleConnexion', methods: ['GET', 'POST'])]
public function connexion() : Response {
    return $this->render('monFormulaireDeConnexion.html.twig');
}

Ensuite, on crée le template Twig correspondant, contenant un formulaire de connexion :

<form action="{{ path('exempleConnexion') }}" method="post">
    <input type="text" name="_username" required/>
    <input type="password" name="_password" required/>
    <button type="submit">Connexion</button>
    <input type="hidden" name="_csrf_token" data-controller="csrf-protection" value="{{ csrf_token('authenticate') }}">
</form>

• La valeur de l’attribut name du champ de login doit être _username.

• La valeur de l’attribut name du champ de mot de passe doit être _password.

• Ce formulaire doit aussi contenir un jeton CSRF (protection contre le cross-site request forgery), dans un input de type hidden (donc caché), nommé _csrf_token dont la valeur est générée avec {{ csrf_token('authenticate') }}.

Enfin, il ne reste plus qu’à éditer le fichier config/packages/security.yaml :

security:
    ...
    firewalls:
       ...
        main:
            ...

            form_login:
                login_path: exempleConnexion
                check_path: exempleConnexion
                default_target_path: maRoute
                always_use_default_target_path: true
                enable_csrf: true

• Le système de sécurité de Symfony redirige les visiteurs non authentifiés vers la route indiquée dans login_path lorsqu’ils tentent d’accéder à une page sécurisée sans être connecté.

• Le paramètre check_path doit correspondre à la route vers laquelle renvoie le formulaire de connexion. Symfony va intercepter les requêtes POST à check_path pour traiter les identifiants de connexion. En cas d’échec de connexion, Symfony redirige l’utilisateur sur login_path, ce qui a pour effet de réafficher le formulaire de connexion.

• Les paramètres default_target_path et always_use_default_target_path permettent de rediriger l’utilisateur vers une route précise après une connexion réussie.

Déconnexion

Maintenant, nous devons gérer la déconnexion. Cela est encore plus simple, car il n’y a même pas de méthode de route ou de formulaire à créer. Il suffit d’éditer deux fichiers :

• Tout d’abord, le fichier config/packages/security.yaml en paramétrant notre route de déconnexion avec une section nommée logout, un peu comme nous l’avons fait pour la connexion :

  security:
      ...
      firewalls:
      ...
          main:
              ...
              logout:
                  path: /cheminRouteDeconnexion
                  target: routeRetour
  

  Dans path, on précise le chemin de la route (par exemple /deconnexion) et dans target la route (cette fois, pas avec son chemin, mais bien avec son nom) vers laquelle est redirigé l’utilisateur après s’être déconnecté.

• Ensuite, on configure une section _security_logout dans le fichier config/routes.yaml :

  _security_logout:
      resource: security.route_loader.logout
      type: service
      methods: ['POST']
  

  Par défaut, toutes les méthodes sont autorisées pour accéder à la route de déconnexion. Dans notre cas, nous limitons cela à POST grâce à l’attribut methods.

Par la suite, quand on voudra générer le lien de la route de déconnexion du côté d’un template twig, il suffira d’utiliser la fonction prédéfinie logout_path() qui génère le lien adéquat (nous n’utiliserons donc pas path, dans ce cas).

Nous n’avons pas beaucoup évoqué la notion de firewall jusqu’ici. Un firewall est la partie de Symfony qui permet de vous authentifier, de savoir qui vous êtes selon les parties du site (les pages) auxquelles vous tentez d’accéder. Les firewall dev est un “faux” firewall utilisé en local pour avoir accès aux outils de développement (entre autres) sur la page web, notamment. Par défaut, vous possédez donc un seul véritable firewall main qui est configuré pour traiter l’accès à toutes les pages du site. Généralement, c’est amplement suffisant, mais on pourrait aussi imaginer avoir un firewall nommé api si le site proposait également une api qui permettrait d’authentifier les utilisateurs différemment, les déconnecter différemment, etc. Et il serait utilisé pour toutes les routes qui commencent par /api/, par exemple. Pour configurer les routes pour lequel un firewall est utilisé, on utilise le paramètre pattern. Comme vous le voyez, main n’en possède pas : par défaut, il permet donc de traiter toutes les routes.

Sécurisation d’action

Bon, pour le moment, vous ne voyez aucune différence (du point de vue d’un utilisateur normal) qui indique que vous êtes bien connecté ! Nous allons effectuer quelques modifications pour changer certains éléments affichés selon l’état de l’utilisateur (connecté ou non).

Dans vos templates Twig, vous pouvez utiliser la fonction is_granted(role) pour vérifier le rôle d’un utilisateur (par exemple, dans une structure conditionnelle) et ainsi afficher ou non certaines sections.

Dans notre cas, nous pouvons par exemple vérifier si l’utilisateur a le rôle ROLE_USER qui est le rôle de base que tous les utilisateurs connectés possèdent (donnés dans la classe Utilisateur) :

{% if is_granted('ROLE_USER') %}
<!-- Utilisateur connecté -->
{% else %}
<!-- Utilisateur non connecté -->
{% endif %}

On peut bien sûr utiliser not is_granted('...') pour vérifier qu’un utilisateur ne possède pas un rôle.

Il est aussi possible d’utiliser app.user qui ne vérifie pas les permissions mais qui renvoie l’utilisateur courant (donc, s’il n’y en a pas, l’application renvoie null) ou bien is_granted("IS_AUTHENTICATED") qui vérifie que l’utilisateur est connecté, sans vérifier de rôles en particulier. Cette dernière approche est utile si on ne donne pas le ROLE_USER par défaut, comme ce qui est fait dans l’application quand on génère l’entité utilisateur avec make:user.

Du côté des contrôleurs, il est aussi possible de limiter l’accès à des routes à certains rôles en utilisant l’attribut #[IsGranted(role)] au-dessus d’une route :

use Symfony\Component\Security\Http\Attribute\IsGranted;

#[IsGranted('ROLE_ADMIN')]
#[Route('/exemple', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(): Response
{
    //Seuls les utilisateurs possédant le rôle `ROLE_ADMIN` ont accès à cette route.
}

Si jamais il y a plusieurs méthodes autorisées pour une route (par exemple, GET et POST) et que l’on souhaite seulement interdire l’accès à cette route pour une méthode donnée, on peut vérifier quelle est la méthode utilisée en spécifiant l’arguments methods de l’attribut IsGranted:

#[IsGranted('ROLE_USER', methods: ['POST'])]
#[Route('/exemple', name: 'route_exemple', methods: ["GET", "POST"])]
public function methodeExemple(Request $request): Response
{
    //Tous les utilisateurs (connectés ou non) peuvent accéder à cette route avec la méthode 'GET' mais seuls les utilisateurs qui ont le rôle 'ROLE_USER' (donc, tous les utilisateurs connectés) peuvent déclencher cette route avec la méthode 'POST'.
}

Alternativement, si on ne souhaite pas utiliser IsGranted, il est possible de faire la même chose avec la méthode isMethod(method) de l’objet Request et refuser l’accès à la route en utilisant denyAccessUnlessGranted(role) si l’utilisateur ne possède pas le rôle spécifié :

#[Route('/exemple', name: 'route_exemple', methods: ["GET", "POST"])]
public function methodeExemple(Request $request): Response
{
    if($request->isMethod('POST')) {
        $this->denyAccessUnlessGranted('ROLE_USER');
        //Si l'utilisateur n'a pas le rôle 'ROLE_USER' l'exécution s'arrête et une page d'erreur est affichée.
    }

    //...
}

Notez qu’il est aussi possible de simplement faire de routes séparées avec le même chemin, une en GET et une en POST et utiliser l’attribut IsGranted :

use Symfony\Component\Security\Http\Attribute\IsGranted;

#[Route('/exemple', name: 'route_exemple_get', methods: ["GET"])]
public function methodeExempleGet(): Response
{
    //Tout le monde a accès à cette route.
}

#[IsGranted('ROLE_USER')]
#[Route('/exemple', name: 'route_exemple_post', methods: ["POST"])]
public function methodeExemplePost(): Response
{
    //Seuls les utilisateurs connectés ont accès à cette route.
}

Cependant, comme nous l’avons vu, dans le cadre d’un formulaire, nous pouvons regrouper GET et POST dans la même méthode. Dans le cas particulier où l’on souhaite afficher une page formulaire, mais réserver son traitement à un rôle particulier, on utilisera donc une des techniques présentées ci-dessus. Néanmoins, ce cas de figure ne se produit pas souvent, mais c’est le cas pour notre route feed, par exemple : on souhaite pouvoir afficher la page à tout le monde, mais réserver la création d’une publication aux utilisateurs connectés.

Notification de connexion et déconnexion

Comme notre système de connexion/déconnexion est géré par Symfony, nous ne pouvons pas ajouter de messages flash comme pour une route normale. Mais heureusement, pour cela, il y a les événements ! Durant le cycle de vie de l’application, certains événements comme la connexion ou la déconnexion de l’utilisateur peuvent être captés par le développeur afin de réaliser des actions complémentaires. Les classes qui traitent ces événements sont appelées EventListener.

Ces classes sont regroupées dans le dossier src/EventListener de l’application et se présentent ainsi :

namespace App\EventListener;

use Symfony\Component\EventDispatcher\Attribute\AsEventListener;

class MonEventListener {

    public function __construct(/* Injection de dépendances possible ici*/){}

    #[AsEventListener]
    public function onMonEvent(MonEvent $event) {
        //Méthode déclenchée quand un événement de type `MonEvent` est déclenché
    }

}

• Chaque méthode de la classe peut avoir le nom qu’elle veut, mais il faut qu’elle possède l’attribut #[AsEventListener] et prenne en paramètre l’événement qu’elle souhaite traiter.

• Comme pour les services, il est possible de faire de l’injection de dépendances (de services ou d’autres paramètres) via le constructeur.

Dans notre cas, trois événements vont nous intéresser :

• LoginSuccessEvent : déclenché quand l’utilisateur s’est authentifié avec succès.

• LoginFailureEvent : déclenché quand l’utilisateur n’a pas réussi à s’identifier (mauvais login/mot de passe).

• LogoutEvent : déclenché quand l’utilisateur s’est déconnecté.

À l’aide de ces événements, nous allons pouvoir ajouter des messages flash pour améliorer l’ergonomie de notre site après l’exécution de ces actions. Pour cela, nous pouvons utiliser le service RequestStack qui permet (entre autres) d’ajouter des messages flash :

$flashBag = $this->requestStack->getSession()->getFlashBag();
$flashBag->add(categorie, message);

Concernant le message d’erreur en cas d’identifiants invalides, nous aurions pu récupérer le message d’erreur puis l’afficher directement sur le formulaire via l’objet AuthenticationUtils injecté à l’action de la route de connexion, au lieu d’utiliser des messages flashs.

Sécurisation (suite)

Enfin, il reste un dernier problème à régler : malgré le fait que l’accès à la page “inscription” et la page “connexion” soit masqué sur notre page quand un utilisateur est connecté il peut toujours y accéder en tapant l’URL de la route (vous pouvez essayer), ce qui n’est pas normal.

Il est possible d’utiliser l’attribut #[IsGranted] pour utiliser une condition plus complexe et vérifier, par exemple, qu’un utilisateur donné n’a pas un rôle spécifique :

use Symfony\Component\ExpressionLanguage\Expression;

#[IsGranted(new Expression("!is_granted('ROLE_USER')"))]
#[Route('/exemple', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(): Response
{
    //Seuls les utilisateurs ne possédant pas le rôle `ROLE_USER` ont accès à cette route.
}

Contrairement à l’utilisation habituelle que nous faisions de #[IsGranted], on peut utiliser certaines fonctions et des opérateurs conditionnels, comme dans un template Twig et ainsi faire une condition du style !is_granted('ROLE_USER'), c’est-à-dire “n’est pas authentifié”. Une autre valeur ayant le même effet (dans notre cas) est IS_AUTHENTICATED (à la place du rôle). Cela peut être utile de l’utiliser si on ne donne pas par défaut le rôle ROLE_USER à tous nos utilisateurs connectés.

Cependant, il faut réfléchir en termes d’ergonomie : est-ce qu’un utilisateur connecté tentant d’accéder à ces pages doit recevoir une page d’erreur ou bien être redirigé vers une autre page ? Dans notre cas, nous allons plutôt privilégier la seconde solution. Pour cela, il suffit de regarder les permissions de l’utilisateur à l’intérieur de la route, avec isGranted :

#[Route('/exemple', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(): Response
{
    //Déjà connecté...
    if($this->isGranted('ROLE_USER')) {
        return $this->redirectToRoute('maRoute');
    }
}

Cependant, gardez en mémoire l’utilisation de IsGranted avec une Expression, nous en aurons besoin pour le TD3 !

Finitions

Maintenant, il ne reste plus qu’à finaliser notre site, notamment en reliant nos entités Utilisateur et Publication afin d’enregistrer (et d’afficher) les auteurs d’une publication ! Nous verrons également comment créer une page listant les publications d’un utilisateur, et aussi comment personnaliser certaines pages d’erreurs.

Auteur d’une publication

Avec doctrine, pour associer deux entités, il suffit de créer un attribut faisant référence à une autre classe et utiliser les attributs nécessaires pour préciser le sens et la cardinalité de cette association. Il est aussi possible de paramétrer la stratégie en cas de suppression (mettre à null les colonnes faisant référence ou bien supprimer les entités associées…).

Voici la liste des attributs disponibles, qui devraient notamment vous rappeler celles utilisées avec hibernate en base de données en 2ème année :

• #[ORM\ManyToOne(inversedBy: ...)] : À utiliser dans une relation 1 - plusieurs, du côté de l’entité qui doit posséder une instance de l’entité ciblée. Le paramètre inversedBy permet de spécifier le nom de l’attribut de la classe cible qui fait référence à l’entité (où on place cette annotation).

• #[ORM\OneToMany(targetEntity: Target::class, mappedBy: ...)] : À utiliser dans une relation 1 - plusieurs, du côté de l’entité qui doit posséder une collection de l’entité ciblée (l’attribut est de type Collection). Le paramètre targetEntity permet de spécifier la classe cible. Le paramètre mappedBy fonctionne de la même manière que inversedBy.

• #[OneToOne(mappedBy: ...)] : À utiliser dans une relation 1 - 1. Dans l’autre entité, on utilise le même attribut en remplaçant mappedBy par inversedBy.

• #[ManyToMany(targetEntity: Target::class, mappedBy: ...)] : À utiliser dans une relation plusieurs - plusieurs. Dans l’autre entité, on utilise le même attribut en remplaçant mappedBy par inversedBy. Dans ce cas, une nouvelle table sera créée dans la base de données (table de jointure). Dans une des deux entités, au niveau de l’attribut concerné, il faut alors ajouter une autre attribut #[JoinTable(name: 'nom_table_jointure')] afin de nommer cette table. Le paramètre targetEntity fonctionne de la même manière que pour OneToMany.

La configuration des attributs présentée implique un système bidirectionnel où l’entité A connait l’entité B et inversement. Il est bien entendu possible de faire un système unidirectionnel. Pour cela, il faut placer seulement l’attribut dans une des entités concernées, de ne pas spécifier les paramètres mappedBy et inversedBy et de rajouter l’attribut #[JoinColumn(name: 'parent_id', referencedColumnName: 'id')] où parent_id référence le nom de l’attribut “clé étrangère” (qui va être créé) et referencedColumnName le nom de la clé primaire de la table référencée. Il est aussi possible de créer des auto-références (référence vers la même entité).

Attention, au niveau des attributs des relations OneToOne ou ManyToOne, une clé étrangère est générée dans la base :

• Si on veut que cet attribut ne puisse pas être null dans la base, on ajoute un attribut #[ORM\JoinColumn(nullable: false)].

• Si on veut autoriser le comportement de suppression en cascade du côté de la base lors de la suppression de l’entité cible, il faut aussi spécifier le paramètre onDelete: "CASCADE" dans ce même attribut. Par exemple #[ORM\JoinColumn(nullable: false, onDelete: "CASCADE")].

• On peut aussi spécifier #[ORM\JoinColumn(onDelete="SET NULL")] si on veut appliquer la stratégie de mettre l’attribut référencé à null lors de la suppression de l’entité référencée (au lieu de supprimer complètement la ressource qui lui est liée).

Vous pouvez également consulter une documentation plus complète.

Fort heureusement, Symfony nous permet de mâcher ce travail en utilisant encore une fois la commande make:entity en mettant à jour notre entité cible. Il faut simplement :

1. Déclarer une nouvelle propriété

2. Quand on demande le type, sélectionner au choix : ManyToOne, OneToMany, ManyToMany ou OneToOne. Il est également possible de sélectionner relation : cela affichera des informations pour vous aider à choisir parmi les 4 valeurs précédentes.

3. On précise l’entité cible (avec le nom de sa classe).

4. Selon la relation, on précise ensuite si l’entité cible (clé étrangère) peut être nulle ou non, par exemple, dans le cas de OneToMany.

5. On nous demande ensuite si la relation doit être bidirectionnelle, c’est-à-dire s’il faut aussi mettre à jour l’entité avec laquelle on forme une relation. Si on sélectionne oui, on nous demande aussi si les entités orphelines doivent être supprimées (par exemple dans notre cas, si on retire une publication à un auteur…).

Maintenant que toutes nos publications doivent avoir un auteur, il va falloir un peu modifier notre route feed ainsi que notre template feed.html.twig, afin de prendre en compte les données de l’utilisateur.

L’auteur d’une publication est l’utilisateur actuellement connecté qui envoie le formulaire. Du côté contrôleur, lors de la création d’une nouvelle publication, on peut récupérer l’utilisateur connecté ainsi :

//Dans une méthode d'un contrôleur
$utilisateur = $this->getUser();

Du côté du template, il faut, pour chaque publication :

• Remplacer le “Anonyme” par le login de l’auteur.

• Remplacer l’image de profil “anonyme.jpg” par l’image de profil de l’utilisateur. Cependant, s’il n’a pas de photo de profil (propriété nomPhotoProfil null) alors il faut continuer d’afficher l’image “anonyme.jpg” (image de profil “par défaut”). Pour rappel, les images de profil sont stockées dans img/utilisateurs/uploads et la propriété nomPhotoProfil donne simplement le nom de l’image enregistrée dans ce dossier.

Pour le dernier point, il y a plusieurs possibilités : utiliser un “if/else”. Utiliser une ternaire (Condition) ? (Statement1) : (Statement2). Définir une variable dans le template avec set…

Pour rappel, si une propriété d’un objet est null, alors un test conditionnel “objet.propriete” renvoie simplement false.

Aussi, avec Twig, pour concaténer des valeurs, on utilise le symbole ~ :

{{ "Coucou " ~ prenom ~ " !" }}

Attention de bien respecter un espace avant et après ~.

Tout fonctionne bien, mais il y a néanmoins un petit problème : jetez un œil aux requêtes SQL exécutées lors du chargement du feed, en fouillant dans la barre de débogage (cliquez sur le bouton qui a une forme de base de données). Si vous avez un ensemble de publications avec X auteurs différents, il y a X+1 requêtes exécutées ! Pourquoi ça ?

Quand on utilise un ORM avec des entités en relation, il existe deux modes de chargement de données d’autres entités : le lazy loading et le eager loading. Le lazy loading consiste à ne charger des données que quand on en a besoin alors que le eager loading permet de charger tout d’un coup (avec une seule requête, si possible).

Doctrine utilise notamment une de ses stratégies au niveau des entités en relation. Par exemple, quand on charge l’auteur d’une publication. Par défaut, doctrine utilise le lazy loading pour cet attribut. Cela signifie que :

• Quand on exécute findAllOrderedByDate, une première requête est exécutée pour récupérer toutes les publications, mais sans les données sur les auteurs.

• Quand, dans notre template Twig, on lit les données de l’auteur d’une publication pour la première fois, une nouvelle requête est exécutée pour récupérer ses données (et conservées pour ne pas avoir à refaire la requête si on a plusieurs publications avec le même auteur…). Donc, une requête supplémentaire par utilisateur.

Ceci est très mauvais niveau performance ! Notamment si on a beaucoup de publications avec des auteurs différents. Et comme a priori, on souhaite pouvoir lire quelques données sur l’auteur à chaque fois qu’on charge une publication. Pour pallier ce problème, il existe deux solutions : activer le eager loading sur les auteurs d’une publication ou bien modifier notre méthode findAllOrderedByDate pour lui dire de charger les données de l’utilisateur.

En utilisant le eager loading :

• Quand on exécute findAllOrderedByDate, une seule requête est exécutée pour récupérer toutes les publications et les données des auteurs (avec une jointure).

• Quand, dans notre template Twig, on lit les données de l’auteur d’une publication, il n’y a pas de nouvelles requêtes exécutées pour récupérer ses données, elles ont déjà été chargées.

Attention, cette stratégie (eager loading) peut sembler pertinente dans ce contexte, car nous savons que nous devons afficher les données de l’auteur sur chaque publication. Mais, dans d’autres contextes où ces données ne seraient pas toujours affichées, on pourrait alors préférer le lazy loading pour ne pas charger trop de données d’un seul coup (ce qui peut aussi réduire les performances inutilement, si on n’a pas besoin de lire toutes les données).

Pour changer la stratégie utilisée pour récupérer les données d’une propriété, il suffit de configurer le paramètre fetch (avec EAGER ou LAZY) dans l’attribut gérant la relation. Par exemple :

#[ORM\ManyToOne(fetch: 'EAGER', ...)]
private ?Entite $monEntite = null;

Une autre solution consiste à utiliser le DQL (doctrine query langage) pour exécuter une requête custom qui chargera également les données de l’utilisateur auteur d’une publication dans findAllOrderedByDate :

class PublicationRepository extends ServiceEntityRepository
{

    //...

    public function findAllOrderedByDate() : array {
        $queryBuilder = $this->createQueryBuilder("p")
            ->select("p", "a") //On sélectionne les données de la publication + celles de l'auteur
            ->join("p.auteur", "a")
            ->orderBy("p.datePublication", "DESC");
        $query = $queryBuilder->getQuery();
        return $query->getResult();
    }
}

Pour en savoir plus sur le DQL, vous pouvez consulter cette note complémentaire à la fin du TD.

Cette deuxième approche a l’avantage de sélectionner sur quelles opérations et pour quelles entités spécifiques, on chargera les données, sans l’activer globalement sur toute la ressource. C’est une approche souvent conseillée dans la plupart des frameworks web (qui proposent généralement les deux approches).

Une stratégie plus poussée nommée EXTRA_LAZY peut aussi être utilisée dans le cadre de collections d’entités, pour ne pas tout charger d’un coup si on la manipule.

Aussi, dans un site concret, on mettrait en place un système de pagination pour charger les publications petit à petit, pour ne pas charger tout à chaque fois (imaginez qu’il y ait 1 million de publications !). Par manque de temps, nous ne le ferons pas dans nos TDs, mais pensez-y si vous développez un site similaire dans le futur. N’oubliez pas que vous pouvez ajouter des méthodes à vos classes de repository et utiliser le DQL pour faire des requêtes plus complexes.

Page d’un utilisateur

Nous allons maintenant créer une page qui regroupera l’ensemble des publications d’un utilisateur précis. À terme, on ajoutera un lien permettant d’accéder à la page d’un utilisateur depuis une publication et un autre dans le menu de navigation afin que l’utilisateur connecté puisse accéder à sa propre page.

Pour récupérer les informations d’un utilisateur précis, on peut utiliser une route paramétrée comme nous l’avons déjà vu : /route/{propriete}/test. On pourrait ensuite alors utiliser le repository de l’entité ciblée puis utiliser findOne ou findOneBy (si la propriété n’est pas la clé primaire) pour retrouver l’entité :

#[Route('/route/{propriete}/test', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(string $propriete, ExempleRepository $repository): Response
{
    $exemple = $repository->findOneBy(["propriete" => $propriete]);
    if($exemple == null) {
        //Message d'erreur + redirection
    }

    //Traitement normal
}

Si cette méthode est bien valide, Symfony propose une méthode encore plus simple : nommer les attributs de la route paramétrée comme les critères de sélection utilisés lors de la requête SQL, puis laisser doctrine faire le reste.

Par exemple, ce bout de code fait exactement la même chose (en arrière-plan) que le précédent :

#[Route('/route/{propriete:exemple}/test', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(?Exemple $exemple): Response
{
    if($exemple == null) {
        //Message d'erreur + redirection
    }

    //Traitement normal
}

Dans l’exemple ci-dessus, Symfony va automatiquement utiliser le repository “ExempleRepository” (car il détecte qu’on souhaite trouver une entité Exemple, d’après les paramètres de la méthode) et faire un appel à findOneBy(["propriete" => {propriete}]) (où {propriete} désigne la valeur de l’attribut {propriete} dans l’URL) afin de placer une valeur dans Exemple. Le ? (devant le type) permet d’autoriser une valeur nulle pour l’attribut.

Il faut donc que le paramètre de la route porte exactement le même nom que la propriété visée dans l’entité (ici “propriete”) suivi du nom exact du paramètre correspondant à l’entité dans la fonction (ici “exemple”), et que la requête ne renvoie qu’une seule entité.

Il est tout à fait possible de combiner plusieurs critères de recherche ! Par exemple, si une entité à une clé primaire composée de deux attributs (ou plus) :

#[Route('/route/{critere1:exemple}/test/{critere2:exemple}', name: 'route_exemple', methods: ["GET"])]
public function methodeExemple(?Exemple $exemple): Response
{
    //Execute (en arrière-plan) : $exemple = findOneBy(["critere1" => {critere1}, "critere2" => {critere2}]);
    ...
}

Il est aussi tout à fait possible de chercher automatiquement plus d’une entité à la fois !

#[Route('/entreprise/{id:entreprise}/employes/{id:employe}', name: 'route_entreprise_employe', methods: ["GET"])]
public function employeEntreprise(?Entreprise $entreprise, ?Employe $employe): Response
{
    /* 
    Execute (en arrière-plan):
    - $entreprise = findOneBy(["id" => {id:entreprise}]);
    - $employe = findOneBy(["id" => {id:employe}]);
    */
    ...
}

Bref, dans la plupart des cas, on cherche une seule entité avec un seul paramètre :

#[Route('/livres/{isbn:livre}', name: 'get_livre', methods: ["GET"])]
public function getLivre(?Livre $livre): Response
{
    /* 
    Execute (en arrière-plan):
    - $livre = findOneBy(["isbn" => {isbn}]);
    */
    ...
}

Dans ce contexte, il est important de placer un point d’interrogation ? devant le type des entités, car la requête peut renvoyer null. (Pour rappel, ? placé devant un nom de classe signifie que l’objet est autorisé à être null).

Vous avez sans doute remarqué que, dans les pages des utilisateurs, les publications ne sont pas triées par ordre décroissant des dates de publications contrairement à la page principale. Ici, vous avez directement utilisé la propriété utilisateur.publications qui n’applique pas de tri (par défaut).

Pour remédier à ce problème, il y a deux solutions possibles :

• Actuellement, vous utilisez (normalement) la propriété publications de l’utilisateur pour afficher ses publications. Pour trier les publications contenues dans cette propriété, il suffit d’utiliser un attribut au-dessus, pour indiquer comment elle doit être triée quand lue depuis la base de données :

  #[ORM\OrderBy(["propriete" => "DESC ou ASC", ...])] : ici, on a le même fonctionnement que pour findBy. On indique dans un tableau la ou les propriétés avec lesquelles on souhaite trier les résultats et le sens (ASC ou DESC) :

    class Entreprise {
  
        #[ORM\OneToMany(mappedBy: 'entreprise', targetEntity: Employe::class)]
        #[ORM\OrderBy(["salaire" => "DESC"])]
        private Collection $employes;
  
    }
  

  Ici, quand on lira la propriété employes d’une entité de type Entreprise, la collection d’employés sera triée selon le salaire des employés (du plus haut au plus bas). Il est possible d’ajouter d’autres critères, en cas d’égalité… Vous l’aurez compris, les propriétés à indiquer pour le tri appartiennent à l’entité cible de la collection.

• Ou bien, on n’utilise pas du tout la propriété publications et on code une méthode dédiée dans PublicationRepository qui récupère les publications d’un utilisateur :

    class PublicationRepository extends ServiceEntityRepository
    {
  
        //...
  
        public function findAllOrderedByDateForUser(Utilisateur $utilisateur) : array {
            $queryBuilder = $this->createQueryBuilder("p")
                ->select("p", "a")
                ->join("p.auteur", "a")
                ->where("a.id = :id") //Protection contre les injections SQL
                ->orderBy("p.datePublication", "DESC");
            $query = $queryBuilder->getQuery();
            $query->setParameter("id", $utilisateur->getId()); //On injecte le paramètre ici
            return $query->getResult();
        }
    }
  

  Cette méthode à l’avantage de ne pas systématiquement trier la propriété publications d’un objet Utilisateur quand on le lit contrairement à la méthode précédente. On pourrait même se passer complètement de la propriété publications avec cette méthode.

  Ensuite, il ne reste plus qu’à injecter le repository dans l’action pagePerso, récupérer les publications de l’utilisateur, les passer au template puis les utiliser dans la boucle d’affichage.

  N’hésitez pas à consulter la note complémentaire à la fin du TD.

Vous connaissez déjà la méthode path pour créer une URL depuis le nom d’une route dans un template Twig. Mais comment faire quand le chemin de la route contient des paramètres, comme pour les pages des utilisateurs ? Il suffit d’ajouter les paramètres correspondants à path :

<a href="{{ path('route_exemple', {'propriete': 'coucou'}) }}">Exemple</a>

Donc, si la route route_exemple possède pour chemin /route/{propriete}/test l’exemple ci-dessus générera :

<a href="/route/coucou/test">Exemple</a>

Rappelons que Symfony met à disposition un objet app.user représentant l’utilisateur connecté. On peut donc accéder à ses propriétés, par exemple app.user.id, etc…

Comme évoqué plus tôt, dans un site concret, on aurait plutôt un système de pagination plutôt que de charger toutes les publications de l’utilisateur d’un seul coup, avec une requête dédiée (on pourrait alors éventuellement se passer de l’attribut publications dans la classe Utilisateur, ou bien l’utiliser différemment).

Inclure des templates

Nous avons dupliqué le code permettant d’afficher la liste des publications dans feed.html.twig et page_perso.html.twig : ce n’est pas bon !

Une autre fonctionnalité de Twig que nous n’avons pas abordé jusqu’ici est l’inclusion de template : il est possible d’inclure le code d’un template dans un autre template. Ce mécanisme est différent de l’extension de template que nous utilisions jusqu’ici et qui consistait à “hériter” du code d’un template et redéfinir certaines parties. L’inclusion de template se rapproche plus d’une fonction qu’on peut réutiliser dans plusieurs autres templates. De plus, un peu comme une fonction, on peut passer des paramètres aux templates inclus.

L’instruction pour inclure un template est la suivante :

{{ include(cheminTemplate, {'param1': ..., 'param2': ... }) }}

• cheminTemplate : correspond au chemin du template à partir de la racine : le dossier templates (comme on étend un template, ou qu’on l’utilise dans un contrôleur…)

• Le second paramètre est optionnel et permet de passer des paramètres utilisables par le template inclus.

Imaginons par exemple que je définisse le template livres/livres.html.twig suivant, permettant de générer le code HTML pour présenter les détails d’un livre :

<h2>Livre: {{ livre.tire }}</h2>
<p>Année: {{ livre.anneePublication }}</p>
<p>Auteur: {{ livre.auteur }}</p>

Je peux inclure ce template dans un autre template à tout moment, en passant le livre en paramètre. Par exemple, imaginons que je définisse un template best_seller.html.twig qui liste les trois livres les plus vendus cette année. Je possède un objet “top” contenant quatre propriétés : annee, livre1, livre2 et livre3.

<h1>Best-sellers de {{ top.annee }}:</h1>
<p>Top 1:</p>
{{ include('livres/livres.html.twig', {'livre': top.livre1}) }}
<p>Top 2:</p>
{{ include('livres/livres.html.twig', {'livre': top.livre2}) }}
<p>Top 3:</p>
{{ include('livres/livres.html.twig', {'livre': top.livre3}) }}

Bien sûr, la modélisation pour ce problème n’est pas la meilleure, et même dans le template, nous aurions pu utiliser une boucle, mais cela permet d’illustrer efficacement la fonctionnalité d’inclusion.

Tout cela va trouver son intérêt si le template est réutilisé dans plusieurs pages différentes. Par exemple, je pourrais réutiliser dans la page illustrant les détails d’un livre. Ou alors, si j’utilise un formulaire à plusieurs endroits de mon site, je peux le placer dans un template et l’inclure là où il y a besoin.

Il est intéressant de noter que le template inclus ait accès à toutes les variables déjà accessibles (ou définies) par le template qui l’appelle.

Il est d’ailleurs tout à fait possible que ce template “étende” un autre template, comme nous l’avons fait pour la plupart des templates que nous avons créé jusqu’à présent. Finalement, on peut voir l’extension de templates comme de l’héritage (et la redéfinition de blocks comme de la réécriture de méthodes) et l’utilisation d’un template à l’intérieur d’un autre template comme un appel de fonction, par exemple.

On pourrait même aller plus loin et avoir un template liste_publications.html.twig si l’affichage d’une liste de publications était plus complexe qu’une simple boucle et se répétait sur plusieurs pages. Ce template pourrait lui-même utiliser notre nouveau template publication.html.twig…

Environnement et pages d’erreurs

Actuellement, quand une page d’erreur s’affiche, vous avez une trace assez complète et beaucoup d’autres informations qui vous permettent de trouver l’erreur. Toutes ces données sont disponibles, car nous sommes dans un environnement d’application appelé dev sur Symfony. Cet environnement permet aussi d’accéder à la barre de débogage dont nous avons parlé plus tôt.

Bien sûr, toutes ces informations ne doivent pas apparaître quand le site est publié. On change alors d’environnement pour prod. Il est aussi possible d’avoir des fichiers de configurations différents par environnement (pas la même base de données entre dev et prod, par exemple).

Vous avez sans doute remarqué que parfois, le chargement des pages est un peu long après certaines de vos modifications. C’est aussi une des différences majeures entre l’environnement prod et dev. Quand on est sur l’environnement de production, Symfony utilise un cache qui permet d’accélérer les prochaines requêtes. Néanmoins, après une modification du code, il est nécessaire de vider le cache pour constater les mises à jour.

En mode développement (dev), le cache n’est pas vraiment activé. Après une modification du code, il se régénérera automatiquement, ce qui fait que les requêtes sont plus longues de manière générale. À l’inverse, vous remarquerez que votre site est beaucoup plus rapide en mode prod (et heureusement !).

Il faut donc penser à vider le cache quand on fait un changement dans le mode prod avec la commande :

php bin/console cache:clear

Ou bien :

php bin/console c:c

Ce n’est pas très contraignant, car le développeur ne travaille pas (ou peu) dans le mode prod. Ce mode est utilisé là où le site est hébergé publiquement. Celui-ci va plutôt subir de “grosses” mises à jour ponctuelles plutôt que plein de petites mises à jour de code toutes les minutes, comme une application en développement. Après une grosse mise à jour du site, il suffit alors de vider le cache une fois.

Pour changer d’environnement, il suffit d’éditer la variable APP_ENV dans le fichier .env (ou .env.local) à la racine du projet.

Quand on passe en mode prod il est impératif de compiler les assets afin que les ressources (css, scripts, images…) soient transférés depuis le dossier assets vers le dossier public/assets (l’asset mapper est désactivé en production). Cela se fait avec cette commande :

php bin/console asset-map:compile

Pour en revenir aux pages d’erreurs celles-ci ont un look bien différent en mode prod qu’en mode dev. Ce qui est bien, c’est que Symfony nous permet de les customiser !

Il faut d’abord créer le chemin de répertoires templates/bundles/TwigBundle/Exception. Ensuite, on peut créer :

• Un template pour un code d’erreur HTTP spécifique (403, 404, 500, etc…). Ce template doit s’appeler précisément errorXXX.html.twig où XXX est le code de l’erreur.

• Un template général error.html.twig qui sera chargé par défaut, s’il n’existe pas de template pour le code HTTP ayant déclenché l’erreur.

Ces templates seront chargés automatiquement (en mode prod) si une erreur survient.

Vous remarquerez que, si vous êtes connectés et que vous accédez à une route inexistante (404), la page vous apparait comme si vous étiez déconnecté. Malheureusement, c’est une petite limitation de Symfony à ce niveau, car l’ordre d’exécution des processus pour résoudre une route fait que les informations de l’utilisateur ne sont pas encore chargées à ce stade-là (car la route n’existe simplement pas dans l’application). C’est donc “normal” que le menu de navigation ne s’affiche pas comme pour les autres erreurs.

Conclusion

Vous possédez maintenant de solides bases pour construire des sites web à l’aide de Symfony ! Dans le prochain TD, nous irons un peu plus loin en intégrant du JavaScript, de nouvelles fonctionnalités, puis nous nous intéresserons également à la mise en place d’un système de paiement pour permettre à certains utilisateurs de bénéficier d’un accès “Premium” à notre site !

Lien avec le cours de complément web (RACDV)

• Le fichier de configuration config/services.yaml est très proche du fichier de configuration du conteneur de services que certains d’entre vous aviez codé (lors du TD4 de complément web, au semestre 4). Nous avions aussi codé un équivalent de ce fichier sous la forme d’une classe de configuration PHP.

• Le concept de dépendre d’interfaces plutôt que de classes concrètes a aussi été abordé lors du TD4 de complément web. Cela permet à votre application d’être plus modulable et plus facilement testable !

• Nous avions déjà vu la syntaxe des constructeurs avec visibilité devant les arguments, afin de déclarer un attribut.

Des notifications plus élégantes

Si le temps le permet, vous pouvez consulter cette note complémentaire qui permet de remplacer nos messages flashs par des notifications plus élégantes.