L'ensemble de ce cours se base sur la version 6 de Symfony

Objectifs du S3

• Comprendre le concept de MVC (Modèle-Vue-Contrôleur)

• Comprendre le fonctionnement d'un framework

• Installer et débuter avec le framework Symfony

Durant ce semestre nous aurons pour fil rouge la construction d'un mini forum de discussion. Vous pouvez en voir une demonstration ici : https://forum.davidannebicque.ovh

Ajoutez une entité "Auteur" comprenant les champs suivant :

• Nom

• Prénom

• Email

• droit (auteur/administrateur)

Un auteur peut publier des posts, modifier ses posts.

Un auteur avec des droits administrateurs peut modifier tous les posts, et gérer les catégories.

Modifiez l'entité post pour lui ajouter un auteur et sauvegardé l'auteur dans le post (dans un premier temps on fera une liste déroulante des auteurs)

Créer un formulaire pour pouvoir ajouter des auteurs.

Etapes

• Créer l'entité auteur (make:entity)

  • Ajouter les 4 champs (nom, prénom, email, droit)

  • Mettre à jour la base de données (bin/console d:s:u -f depuis docker)

• Créer un contrôleur ou lancer la commande make:crud sur auteur

  • Créer ou améliorer le formulaire avec les labels des champs, le mettre en forme en utilisant un thème.

• Modifier l'entité post pour faire une relation avec auteur

  • make:entity sur Post

  • La relation est de type ManyToOne

• Modifier le formulaire (PostType) pour ajouter une liste déroulante avec les auteurs (entity Auteur)

Depuis la version 4, Symfony à grandement simplifié la structure de ses répertoires et à normalisé les appellations pour coïncider avec la pratique de la majorité des framework.

Symfony à également abandonné la notion de Bundle, qui était nécessaire pour développer son projet.

Architecture globale

• bin/ : contient la console

• config/ : contient les configurations des différents bundles, les routes, la sécurité et les services

• public/ : c'est le répertoire public et accessible du site. Contient le contrôleur frontal "index.php" et les "assets" (css, js, images, ...)

• src/ : contient votre projet (M et C du MVC)

• templates/ : contient les vues (V du MVC)

• var/ : contient les logs, le cache

• vendor/ : contient les sources de bundles tiers et de Symfony

Configuration

Vous remarques des fichiers au format yaml, le format par défaut pour la configuration de Symfony. Vous pouvez aussi remarquer les répertoires dev, prod et test. Ces répertoires permettent de facilement différencier une configuration pour un environnement de développement, pour le site en ligne, ou encore pour un contexte de test.

Par exemple, lorsque l'on développe, on ne souhaite pas réellement envoyer les mails aux usagers, par contre, on souhaite les visualiser. On peut donc configurer ce comportement dans le répertoire dev, pour le bundle de gestion des emails. Un autre exemple est la gestion des logs. En dev, on ne souhaite pas les conserver, mais les afficher, en production, on ne souhaite surtout pas les afficher, mais les stocker dans des fichiers.

Le concept est donc de définir le comportement global quelque soit l'environnement dans le fichier à la racine de config/packages, et de spécifier un comportement en fonction de l'environnement dans les répertoire dev, prod ou test.

Src

Dans ce répertoire se trouve toute la logique de l'application, les contrôleurs, les modèles, nos classes spécifiques, les services, ...

• Controller/ : Tous les contrôleurs de l'application, accessibles par des routes

• Entity/ : Les classes spécifiques pour la gestion de l'application, des données et des API

• Migrations/ : Contient les fichiers permettant la mise à jour de la base de données pour chaque modification effectuée sur la structure.

• Repository/ : Est très généralement lié à une entité, et permet d'ajouter des requêtes spécifiques.

Tous ces points seront détaillés dans les parties suivantes.

Principe général de fonctionnement de Symfony

Première page avec Symfony

Pour créer une page dans Symfony, il faut, au minimum :

• Une route : pour faire le lien entre une URL et une méthode d'un contrôleur

• Un contrôleur : qui contient des méthodes, chacune, en générale, associée à une route

• Une méthode : permet l'execution d'une action précise, généralement en lien avec une route

Premier controller

<?php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;

class LuckyController
{
    public function number(): Response
    {
        $number = random_int(0, 100);

        return new Response(
            'Lucky number: '.$number
        );
    }
}

Ce code est votre premier contrôleur (à déposer dans src/Controller). Ce contrôleur est composé d'une méthode qui calcul un nombre aléatoire et retourne une réponse. Ce code n'utilise pas directement les vues de Symfony, et ne fonctionne pas (en tout cas il n'est pas possible de l'appeler), car il n'est pas lié à une route.

Définir une route

Nous allons utiliser les Attributes, qui permettent une syntaxe plus simple, et une proximité entre la définition de la route et la définition de la méthode (il existe d'autres façons de faire, qui peuvent avoir leurs avantages et leurs inconvenients et dépendre des pratiques de l'entreprise).

Les Attributes, contrairement aux annotations, ne nécessitent pas de dépendances supplémentaires. En effet les Attributes sont maintenant natifs en PHP 8.0, et sont supportés par Symfony depuis la version 5.1.

Modifions le contrôleur précédent en intégrant directement la route sous forme d'Attribute.

<?php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class LuckyController
{
    #[Route("/lucky/number", name:"app_lucky_number")]
    public function number(): Response
    {
        $number = random_int(0, 100);

        return new Response(
            'Lucky number: '.$number
        );
    }
}

Pour accéder a cette route, il faut maintenant taper l'URL suivante : http://localhost:8000/lucky/number si vous executez le serveur de développement de Symfony. Sinon, il faut taper l'URL suivante : http://localhost:8000/public/index.php/lucky/number. La partie locahost:8000 est à adapter en fonction de votre configuration.

Si vous testez cette URL, vous devriez voir affiché le nombre aléatoire. Cependant, regardez attentivement et vous verrez que ce qui est renvoyé n'est pas du HTML, mais du texte brut. C'est parce que nous n'utilisons pas encore les vues de Symfony, et que nous retournons directement une réponse sans plus d'information que cela sur le format retourné.

Ajout d'une vue

Cette solution fonctionne, mais écrire tout le code "HTML" dans la méthode n'est pas très pratique. Nous devons donc écrire des vues. Par défaut, Symfony utilise Twig. Pour cela, il faut l'installer

composer require twig

# Uniquement si vous n'avez pas installé le projet avec toutes les dépendances --webapp

Il faut ensuite modifier le contrôleur pour utiliser les vues.

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class LuckyController extends AbstractController
{
    #[Route("/lucky/number", name:"app_lucky_number")]
    public function number(): Response
    {
        $number = random_int(0, 100);

        return $this->render(
            'lucky/number.html.twig',
            [
                'number' => $number
            ]
        );
    }
}

Il faut maintenant écrire la vue.

{# templates/lucky/number.html.twig #}
<h1>Your lucky number is {{ number }}</h1>

Et Voilà !

Création avec la console

Symfony propose un outil qui se nomme "maker" qui permet de générer du code pour nous. Le code produit est très générique, ne correspond pas forcément exactement à vos besoin, mais permet d'avoir une première base de travail et une structure pour vos différents fichiers.

Pour installer le maker (si vous n'avez pas installé un projet avec toutes les dépendances --wepabb), en étant dans votre projet :

composer require maker --dev

ou

symfony composer require maker --dev

Ensuite pour utiliser le maker, dans le projet saisir la commande suivante

bin/console make:controller NomDuController

Cette commande va générer un controller nommé "NomDuController" (dans src/controller) et la vue associée dans le repertoire templates/NomDuController, avec une méthode index.

Présentation

Découvrir et appréhender un framework PHP web.

Pré-requis

• PHP

• Programmation Orientée Objet

• Structure MVC

• Base de données

Le concept du MVC

Le concept de programmation MVC consiste à séparer les différentes parties d'un projet web en trois parties distinctes : le modèle, la vue et le contrôleur. Le modèle représente les données et la logique métier, la vue représente l'interface utilisateur et le contrôleur gère les interactions entre le modèle et la vue. Le contrôleur reçoit les demandes de l'utilisateur, récupère les données nécessaires auprès du modèle et les transmet à la vue pour affichage.

L'intérêt d'utiliser le concept de programmation MVC est de séparer les différentes parties d'un projet web en trois parties distinctes, ce qui permet une meilleure organisation et une plus grande facilité de maintenance du code. En séparant la logique métier, l'interface utilisateur et les interactions entre les deux, il est plus facile de faire des modifications sans affecter les autres parties du code. Cela permet également une meilleure collaboration entre les développeurs travaillant sur le même projet.

C: Controller / Contrôleur

C'est lui qui reçoit l'interaction (la demande/request) du visiteur. Il se charge de récupérer les éléments nécessaires auprès du/des modèle(s). Il transmets toutes les données nécessaires à la vue.

V: View / Vue

C'est lui qui apporte la réponse (response/render) au visiteur. Une vue peut être une page web, un fichier pdf, ... Ne se préoccupe que de l'affiche des informations, n'assure aucun traitement

M: Model / Modèle

C'est lui qui s'occupe de récupérer et préparer les données. Le modèle peut être en lien avec une base de données. Le modèle peut être en lien avec des API. Le modèle prépare les données pour qu'elles soient facilement manipulables par la vue.

Notion de Framework

Définition générale

En programmation informatique, un framework ou structure logicielle est un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d’un logiciel (architecture). Un framework se distingue d’une simple bibliothèque logicielle principalement par :

• son caractère générique,

• faiblement spécialisé,

• contrairement à certaines bibliothèques ;

Un framework peut à ce titre être constitué de plusieurs bibliothèques chacune spécialisée dans un domaine. Un framework peut néanmoins être spécialisé, sur un langage particulier, une plateforme spécifique, un domaine particulier : reporting, mapping, etc. ;

Le cadre de travail (traduction littérale de l’anglais : framework) qu’il impose de par sa construction même, guidant l’architecture logicielle voire conduisant le développeur à respecter certains patterns (modèle de conception) ; les bibliothèques le constituant sont alors organisées selon le même paradigme.

Framework Orienté Objet

Un framework dit orienté objet est typiquement composé de classes mères qui seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui utilise le framework.

Le développeur qui utilise le framework pourra personnaliser les éléments principaux du framework par extension, en utilisant le mécanisme d’héritage : créer des nouvelles classes qui contiennent toutes les fonctionnalités que met en place le framework, et en plus ses fonctionnalités propres, créées par le développeur en fonction des besoins spécifiques à son application.

Symfony

• Framework MVC en PHP 5 (V2), PHP 7 (V3, V4 et V5 ), PHP 8.1 (V6) libre

• Développé en 2005 par la société Sensio pour répondre à ses besoins

• Division de la société Sensio en deux entités l’agence Web et l’entreprise qui soutient et maintient Symfony : SensioLabs, dirigée par Fabien Potencier, l’auteur de Symfony

• Framework français !, De renommée mondiale

• Premier framework en France et en Europe

SYMFONY : AVANTAGES

• Connectable à presque tous les SGBD

• De nombreux Bundles, contributeurs, utilisateurs

• Moteur de template puissant et simple

• Depuis la V4, Symfony est très léger et très rapide

Symfony V4 : Un retour aux bases

Avec sa version 4 (et suivante), Symfony à pris un virage important par rapport aux précédentes versions, et se rapproche des "standards" de la majorité des framework, mais à aussi grandement optimisé son poids et sa vitesse d'exécution. Dans une grande logique de simplification Symfony à également automatisé de nombreux mécanismes qui auparavant auraient impliqués de nombreuses lignes de configuration.

SKELETON ET FLEX

La version Skeleton de Symfony : Apporte un framework Symfony très léger, avec le minimum pour faire fonctionner un controller.

La version 4 de Symfony introduit Flex qui est un gestionnaire de "recipes" (recettes), qui permet l'ajout de fonctionnalité à Symfony (gestionnaire de vue, de base de données, d'email, ...) avec un mécanisme d'auto-configuration de ces "bundles". Cela permet donc de fournir par défaut un framework très léger, avec une grande facilité pour lui ajouter tous les composants nécessaires, sans en mettre plus que nécessaire.

Par défaut Symfony version Skeleton ne sais rien faire ! Par contre, il n'embarque pas des dizaines de Bundles dont vous n'aurez peut être jamais besoin (fonctionnement des versions 2 et 3 avec plus de 46 bundles par défaut, contre 10 aujourd'hui).

Grâce à Flex vous installez rapidement le nécessaire pour répondre à votre projet.

Symfony V5 : Continuer vers la simplification et la standardisation

Avec sa version 5 (et suivante), Symfony continue sa simplification en facilitant l'usage de nombreux composants redéfinis et devenus génériques.

Installations (SF6)

Configuration requise pour votre serveur

• Un serveur Web

• PHP 8.1 ou supérieur

• Une maîtrise de son système d'exploitation ! (fichiers cachés, variables PATH, php.ini, console...)

Symfony - Eco-système

Symfony nécessite tout un environnement pour fonctionner. Symfony implique aussi différents "langages" et utilise un vocabulaire spécifique (souvent repris dans d'autres frameworks).

Composer

Le logiciel Composer trouve son équivalent pour le front avec npm ou Yarn

ENTITÉ (EQ. DU MODÈLE)

ORM : OBJECT RELATIONNAL MAPPING

Repository

Classe PHP qui fait le pont entre une entité et l'ORM, il permet notamment de structurer des requêtes complexes.

YAML

Format de structuration de données très utilisé dans Symfony, mais on peut utiliser du XML, du PHP ou encore les annotations (PHP 7) ou les attributs (php 8), les fichiers de configurations par défaut sont en YAML.

Annotations

Commentaire PHP directement dans les classes utiles (controller, entité, ...) interprété par Symfony pour générer des fichiers de configuration ;

Attributes

Les Attributes sont la nouvelle version des annotations, intégrés nativement dans les versions 8 et supérieures de PHP. Les Attributes sont une forme de données structurées, qui permet d'ajouter des métadonnées à nos déclarations de classes, propriétés, méthodes, fonctions, paramètres et constantes. Ils vont nous permettre de définir de la configuration au plus près du code, directement sur nos déclarations.

Routes

Les routes permettent de faire un lien entre une URL et un contrôleur.

Bundles

Sorte de modules Symfony qui peuvent contenir tout et n'importe quoi ; C'est la force de Symfony les modules peuvent fonctionner indépendamment et même sur d'autres structures PHP, autre framework etc.

ENVIRONNEMENTS

Symfony propose par défaut 2 environnements : dev et prod qui permettent de donner des configs différentes en fonction de l'environnement de travail ;

• dev permet une utilisation sans cache avec des outils de dev comme le profiler ;

• prod lui permet d'utiliser le site avec le cache et sans aucun message d'erreurs.

De plus on peut configurer les différents environnements pour par exemple rediriger tous les mails vers toto@titi.com en dev et laisser le fonctionnement normal pour prod ; pratique pour les debugs. Le changement d'un environnement à un autre se faire en modifiant la ligne suivante dans le fichier ".env" (ou .env.local) :

Profiler

Le profiler est un outil puissant (et indispensable) pour débuger une application. Par défaut le profiler n'est pas installé. Pour l'ajouter il faut exécuter la commande suivante :

Le profiler est toujours visible en bas de la page en mode développement.

Maker

Le maker est un outil puissant pour générer du code, et des éléments dans notre projet. Par défaut le maker n'est pas installé. Pour l'ajouter il faut exécuter la commande suivante :

Il est assez facile de modifier le maker pour que le code généré corresponde exactement à notre projet et nos attentes.

Moteur de template

Introduction

Dans Symfony la notion de modèle se retrouve sous la forme (entre autre) d'une Entité. Une entité est une classe PHP, qui peut être connectée à une table de votre base de données via l'ORM. Lorsqu'une entité est liée à une table, via l'ORM, il y a en général un fichier "repository" associé. Un repository permet la génération de requêtes simples ou complexes et dont le développeur peut modifier à volonté.

Un ORM (Object Relation Mapper) permet de gérer manipuler et de récupérer des tables de données de la même façon qu'un objet quelconque, donc en gardant le langage PHP. Plus besoin de requête MySQL, PostgresSQL ou autre.

Symfony utilise Doctrine comme ORM dans son système par défaut. Nous allons utiliser Doctrine mais vous pouvez utiliser d'autres systèmes si vous le souhaitez. Doctrine peut-être géré de plusieurs façon : XML, JSON, YAML, PHP et en Annotation nous allons utiliser ce dernier format de données.

Vous êtes libre d'écrire le code qui permet le traitement métiers en dehors des entités et d'avoir votre propre logique d'organisation.

Mise en application

Configuration

Comme à chaque fois, il est d'abord nécessaire d'installer les bundles nécessaires pour manipuler la base de données avec un ORM. Il vous faut donc exécuter la commande ci_dessous :

On va également installer, si vous ne l'avez pas encore fait, le bundle "maker" qui contient des outils pour générer du code sous Symfony grâce à la console.

Une fois ces deux éléments installés, il faut configurer la connexion à la base de données. Pour ce faire, il faut éditer le fichier .env à la racine de votre projet, qui doit normalement contenir une ligne d'exemple.

Création de la base de données

Une fois le fichier à jour avec vos données, vous pouvez créer votre base de données depuis la console.

Les modifications de structure de votre base de données devront être réalisées avec la console pour que Symfony puisse faire le lien entre les tables et l'ORM.

Création d'une entité liée à une table

Utilisez la commande make:entity (qui est dans le bundle maker) pour avoir une série de question vous permettant de créer votre entité avec l'utilisation de l'ORM Doctrine. Vous pouvez créer une nouvelle entité ou modifier (ajouter des champs) une entité déjà existante en saisissant son nom.

Vous allez devoir répondre à une suite de question avec le nom de l'entité (par défaut cela donnera le nom de la table), et les champs à créer. Dans Symfony une entité possède toujours un champs id, qui est la clé primaire et qui est auto-incrémenté. Vous ne devez donc pas l'ajouter dans la console.

Pour la création d'un champs, il vous faudra donner :

• son type

• sa taille le cas échéant

• si ce champs peut être null

• s'il doit être unique (index)

Vous pouvez obtenir la liste des types supportés en tapant "?" à la question du type.

Une fois terminé, le fichier d'Entité et le repository associé sont générés.

Exemple dans la console :

Et le code de l'entité généré dans src/Entity/Product.php :

A ce stade l'entité est créé, mais n'existe pas dans la base de données. Il reste deux étapes à exécuter.

Mettre à jour votre base de données : méthode 1

Sans générer de fichier de migration (qui contient toutes les instructions SQL à exécuter sur la base de données, notamment pour le déploiement d'une mise à jour)

Mettre à jour votre base de données : méthode 2

La création d'un fichier de migration qui va contenir le code SQL a exécuter en fonction de votre SGBD.

La mise à jour de votre base de données en fonction du fichier précédemment généré.

Si vous consultez votre PHPMyAdmin vous verrez la table apparaître.

Modifications de champs et lien base de données

Pour modifier des champs vous pouvez éditer directement le code généré dans la partie annotation: nom (par défaut le nom de la variable), taille, type.

Pour ajouter des champs il vous faut relancer la commande make:entity en remettant le nom de votre entité.

Après chaque modification ou ajout il faut de nouveau générer le fichier de migration et mettre à jour la base de données. Vous pouvez bien sûr modifier ou créer plusieurs entités avant de faire une mise à jour de votre base de données.

ORM

Une fois la base de données mise en place on va pouvoir insérer, modifier, supprimer et récupérer des informations de la base de données sans saisir de requêtes via des méthodes en initialisant l'entité fraichement créée :

Il existe à la place de $em->persist, $em->remove($post); qui permettra de faire une suppression.

Exercice

• Configurer votre base de données (dupliquer le .env en .env.local et modifier les informations dans le .env.local)

• Créer la base de données (bin/console doctrine:database:create)

• Créer une entité (bin/console make:entity), nommée Categorie et ajouter les champs suivants

  • titre string 150 caractères

  • ordre int

• L'id sera automatiquement ajouté

• Créer un nouveau contrôleur nommé "CategorieTestController"

• Ajouter une route pour créer un nouvel enregistrement

  • Créer un objet Categorie et compléter les informations (titre, ordre)

  • Récupérer la connexion à doctrine ($em = $this->getDoctrine()->getManager())

  • Associer l'instance de Categorie avec l'ORM ($em->persist($categorie))

  • Enregistrer dans la base de données ($em->flush())

• Appeler la route et vérifier que cela s'enregistre dans votre base de données

• Essayer d'appeler la route plusieurs fois.

Recherche d'entité

Symfony et Doctrine proposes des requêtes prédéfinies, qui répondent aux usages les plus courant.

Si $em est le manager associé à une entité :

• $em->find($id); on récupère qu'un seul élément de l'entité avec l'id $id;

• $em->findAll(); on récupère toutes les entrées de l'entité concernée

• $em->findBy($where, $order, $limit, $offset); on recherche avec le tableau $where on tri avec le tableau $order on récupère $limit éléments à partir de l'élément $offset.

• $em->findOneBy($where, $order); on récupère le premier élément respectant le tableau $where et trié avec le tableau $order;

• $em->findByX($search); requêtes magiques où X correspond à n'importe quel champs défini dans votre entité

• $em->findOneByX($search) ; requêtes magiques où X correspond à n'importe quel champs défini dans votre entité

  Par exemple findBySlug('home'); ou findByTitle('Bonjour); génèrera des requêtes de recherche automatiquement. Pour les requêtes avec plusieurs éléments il faudra faire une itération (foreach) ou lister les différents éléments.

Exemple

Si aucune requête prédéfinie ne correspond à vos besoin, vous pouvez bien sûr en créer une en passant par le repository.

Vous pouvez également générer vos requêtes manuellement pour avoir une requête complexe et précise directement dans le controller mais idéalement il faudrait le placer dans le repository dédié.

Et l'utiliser dans votre controller

Modification

Ce dernier code effectue une création dans la base de données; pour une modification il suffit de modifier l'instanciation de l'entité de la sorte :

ici on récupère le repository de Post et on récupère l'id 1 ; tout le restant du code reste inchangé.

Exercice

• Créer une deuxième entité "Article" avec :

  • titre string 255

  • texte text

  • datePublication datetime

  • auteur string 255

  • image string 255

• Ajoutez des données depuis phpMyAdmin dans la table Article ( 3 articles) ou avec un nouveau contrôler de test

• Modifiez votre contrôleur et la page "/articles" pour afficher tous les articles de votre table, par ordre décroissant (plus récent au plus ancien)

• Modifiez votre page d'accueil pour afficher le dernier article publié.

Objectifs

Tout au long des prochaines séances nous allons mettre en place un système de blog simple permettant de poster des articles, d'obtenir des commentaires et de gérer les accès avec des droits différenciés.

Ce projet va évoluer au fur et à mesure des connaissances de Symfony.

Présentation des routes et des contrôleurs

Une route permet de diriger une url (ou un pattern d'url) vers une méthode de controller appelée Action.

et

Il est possible de décrire des routes selon les formats de fichiers : XML, Classe PHP, en annotation ou avec les Attributes (php8 et +). Pour plus de commodité nous utiliserons les Attributes.

Structures d'une route

Une route peut être constante : /blog ou dynamique : /blog/{slug}. Ici slug englobé de { } devient une variable dynamique qui prend tous les caractères alphanumériques par exemple : /blog/42, /blog/lorem-ipsum, /blog/titi-32\_tata Ces 3 urls correspondent à la méthode ciblée par la route avec une variable slug différente. Cette variable peut être récupérée par le controller.

• Une route est au minimum un chemin (path) et un nom;

• Ces variables peuvent être mises par défaut grâce à "defaults"

• Ces variables peuvent être soumises à une validation de format via "requirements"

• On peut définir un path différent en fonction de la locale

• Vous pouvez cumuler plusieurs routes pour une méthode Action

• On peut spécifier le moyen d'accès à une route (GET, POST, PUT, ...), avec le paramètre "methods"

Attributes

Pour pouvoir utiliser les Attributes il faut :

à ajouter après le namespace dans votre Controller.

Routes et paramètres

Un paramêtre

On définit une variable d'url via des accolades {ma_variable} :

Pour récupérer la variable dans le controller, il suffit de déclarer une variable dans la méthode avec le même nom que la variable d'url.

Valeur par défaut

Pour définir une valeur par défaut, on peut préciser la valeur sur le paramêtre de la méthode :

Si l'utilisateur utilise l'URL /page/, la variable $page sera égale à 1.

plusieurs paramètres

On peut cumuler plusieurs variables :

On pourrait utiliser un autre séparation que le slash, comme par exemple -, . ou _. La seule condition étant que Symfony puisse être en mesure de différencier les paramètres.

Génération d'url

Pour générer une url en PHP on utilise :

Ou sous TWIG on a deux fonctions :

Controller

Les routes redirigent vers une méthode d'un contrôleur (une action); un controller Symfony se nomme de la sorte : NomDuController où le suffixe Controller est obligatoire et le nom du fichier et de la classe est en CamelCase.

Les différentes méthodes se nomment de la sorte :

nomDeLaMethode est lui en miniCamelCase

Dans le cas idéal, le controller doit contenir le minimum de code possible (20 lignes maximum selon les standards de Symfony). Il ne doit que faire le lien entre les différents éléments de l'application et une réponse.

Response

Une méthode d'un contrôleur renvoie toujours un type Response ; il existe plusieurs type de Response : JsonResponse, RedirectResponse, HttpResponse, BinaryFileResponse etc ...

La plus utilisée est Response pour l'utiliser on va ajouter dans le "use" suivant :

et dans la méthode action on :

Affiche à l'écran Ma response. Dans l'état cette réponse n'est pas du HTML, car rien n'est précisé dans le retour de la méthode.

Une méthode render() (définie quand la classe AbstractController dont votre controller doit hériter) permet aux méthodes de récupérer une vue et d'afficher le contenu de la vue compilée avec les différentes variables envoyées.

Ici on va récupérer le template présent dans templates/default/index.html.twig pour affecter la variable variable.

Exercice 1

Les premières étapes consistent à mettre en place les bases de notre projet :

• Une nouvelle installation de Symfony, pour un projet nommé blog

  • On installera toutes les dépendances en une seule fois pour plus de confort : composer require webappdans le dossier blog/

• Un contrôleur et la méthode pour la page d'accueil et la route "/"

• La vue associée à la page d'accueil

• Une page de contact avec une route "/contact" et une vue associée

• Testez vos routes et vos vues, ajoutez un contenu fictif simple pour le moment avec uniquement du HTML comme vous savez le faire depuis le S1.

Les vues/templates

Un template ou une vue est le meilleur moyen d'organiser et de restituer le code HTML à partir de votre application, que vous deviez rendre le code HTML à partir d'un contrôleur ou générer le contenu d'un courrier électronique . Les templates dans Symfony sont créés avec Twig: un moteur de modèle flexible, rapide et sécurisé.

Les vues sont des fichiers HTML qui sont compilés par Symfony pour être envoyés au navigateur. Elles sont stockées dans le dossier templates et sont généralement organisées par contrôleur.

Twig

Twig est le moteur de template par défaut de Symfony. Il permet de faire des boucles, des conditions, des inclusions, des héritages, des filtres, des fonctions, etc. Il est très complet et permet de faire des choses très puissantes. Twig est un langage à part entière, mais il est très simple à apprendre et à utiliser. Twig s'intègre dans le code HTML, il sera ensuite interprété par le moteur Symfony pour générer la page HTML finale.

Exemple d'une vue avec twig

Exemple d'un code que vous pourriez écrire en PHP

Ce même code, écrit avec TWIG serait :

La syntaxe est plus "legére" et moins encombrées des balises PHP. Le code semble donc plus lisible et par conséquent plus facile à maintenir.

Affichage

La syntaxe Twig est basée sur uniquement trois constructions:

• {{ ... }}, utilisé pour afficher le contenu d'une variable ou le résultat de l'évaluation d'une expression;

• {% ... %}, utilisé pour exécuter une logique, telle qu’une condition ou une boucle;

• {# ... #}, utilisé pour ajouter des commentaires au modèle (contrairement aux commentaires HTML, ces commentaires ne sont pas inclus dans la page rendue).

Variables

TWIG est très puissant lorsqu'il s'agit de manipuler des variables. Pour lui, si c'est un tableau associatif ou un objet avec des propriétés cela est identique dans la syntaxe.

Par exemple si vous avez le tableau $tab['param1'] vous écrirez en TWIG

Si vous avez un objet $tab, qui est une instance d'une classe ayant comme propriété $param1, la syntaxe en TWIG sera :

Si vous avez un objet $tab, qui est une instance d'une classe ayant comme propriété $param1, qui est un tableau associatif avec une clé key1, la syntaxe pourrait être :

La manière dont TWIG inspecte votre code pour trouver la meilleure façon d'interpréter une variable est la suivante :

For convenience's sake foo.bar does the following things on the PHP layer:

• check if foo is an array and bar a valid element;

• if not, and if foo is an object, check that bar is a valid property;

• if not, and if foo is an object, check that bar is a valid method (even if bar is the constructor - use __construct() instead);

• if not, and if foo is an object, check that getBar is a valid method;

• if not, and if foo is an object, check that isBar is a valid method;

• if not, and if foo is an object, check that hasBar is a valid method;

• if not, return a null value.

foo['bar'] on the other hand only works with PHP arrays:

• check if foo is an array and bar a valid element;

• if not, return a null value.

Héritage

TWIG permet l'héritage de template via un extends dans les templates enfants :

Dans les templates mère on définit des "block" que l'on vient surcharger dans les templates enfants :

On peut également reprendre le block parent via

On crée donc des templates mère assez flexibles pour pouvoir en hériter et surcharger les différents blocks

Exercice 2

En se basant sur les concept d'héritage, définir un menu avec nos deux pages (accueil et contact) dans le fichier base.html.twig et l'hériter dans les deux autres templates.

Images et CSS/JavaScript

Pour inclure des images, des fichiers CSS ou JavaScript, il faut utiliser la fonction asset() :

Cette fonction va chercher le fichier dans le dossier public/images/logo.png

Asset n'est pas installé par défaut, il faut donc l'installer :

Vous pouvez utiliser cette fonction pour inclure des fichiers CSS ou JavaScript :

Exercice 3

• Créer un dossier css dans le dossier public

• Créer un fichier style.css dans le dossier css, faites un peu de CSS pour mettre en forme votre page d'accueil

• Ajouter une balise link dans le fichier base.html.twig pour inclure le fichier css

• Ajouter une balise img dans le fichier index.html.twig de votre template de la page d'accueil pour inclure une image de votre choix

Logique

• {% %} permet d'utiliser des logiques tels que :

  • {% if %} {% else %} {%endif %} : condition

  • {% for item in items %}{%endfor} : foreach

  • {% set foo='foo' %} : set des variables

Tests

Il est possible d'écrire des tests, la syntaxe est très proche de celle de PHP. Attention toutefois, les opérateurs de comparaison ne s'écrive pas de manière identique.

Le && de PHP s'écrit "and" dans TWIG, et le || de PHP s'écrit "or" dans TWIG.

Il est possible d'avoir des elseif (autant que nécessaire) et un bloc else (1 au maximum)

Boucles

Il n'existe que la boucle for dans TWIG (elle est un peu l'équivalent d'un foreach).

Le code ci-dessous est une boucle qui varie de 1 à 10.

La boucle ci-dessous est une boucle qui parcours une "collection" users (l'équivalent du foreach). Attention la syntaxe est inversée par rapport au PHP

Dans le cadre d'une boucle TWIG propose une variable nommée loop qui permet d'avoir des informations sur la boucle :

La boucle ci-dessous intègre un test. Ce qui simplifie l'écriture. Elle intègre également un else dans le cas ou la boucle ne ferait aucune itération. Il est possible d'utiliser le else sans le if et réciproquement.

Le code ci-dessus serait équivalent en PHP au code suivant:

Exercice 4

• Ajouter une page /articles

• Construire un tableau PHP contenant 3 articles, contenant chacun un titre, un texte et une date

• Passer le tableau à la vue de la page article.

• Afficher le tableau en twig

Exemple de tableau PHP

Exercice 5

• Ajoutez une nouvelle page sur l'url /recherche

• Ajouter une vue avec un formulaire avec une zone de saisie et un bouton submit. Le traitement se fera en poste sur l'url /recherche/resultat

• La vue résultat affichera le contenu de la zone de texte saisie dans la page précédente.

Introduction

Il est fréquent que les entités soient liées entre-elles. Et nous avons la notion de clé étrangère qui peut apparaître dans nos tables. Il est possible (voire nécessaire) de gérer cela avec Doctrine.

Pour ce faire, il va falloir expliquer à Doctrine, les liens qui existent entre nos entités. Et Doctrine, se chargera de créer les clés étrangères où cela est nécessaire.

Relations

Il existe les relations suivantes dans doctrine :

• OneToMany (et son inverse ManyToOne)

• ManyToMany

• OneToOne

Il existe également une notion très importante dans ces relations : propriétaire et inverse.

Propriétaire et inverse

Dans une relation entre deux entités, il y a toujours une entité dite propriétaire, et une dite inverse. L'entité propriétaire est celle qui contient la référence à l'autre entité.

Prenons un exemple simple, les commentaires de nos annonces. En SQL pur, vous disposez de la tablecomment et de la tableadvert. Pour créer une relation entre ces deux tables, vous allez mettre naturellement une colonne advert_id dans la tablecomment. La tablecomment est donc propriétaire de la relation, car c'est elle qui contient la colonne de liaison advert_id.

Unidirectionnelle ou bidirectionnelle

Enfin, une relation peut être unidirectionnelle ou bidirectionnelle. Les relations bidirectionnelles peuvent être gérées automatiquement par Symfony modifiant un peu les entités inverses avec inversedBy et mappedBy.

Dans le cas d'une relation bidirectionnelle, il faut aussi explicité la relation dans l'entité inverse. La relation bidirectionnelle permet de faciliter la recherche d'élement en partant de l'inverse (Article vers Commentaires).

RELATION 1..N (ONETOMANY) ET N..1 (MANYTOONE)

La relation 1..n définit une dépendance multiple entre 2 entités de sorte que la première peut être liée à plusieurs entités

Prenons l'exemple des étudiants et des absences. Un étudiant peut avoir plusieurs (many) absences, mais une absence n'est associée qu'a un (one) seul étudiant.

Cette relation peut donc se résumer à : plusieurs (many) absences pour un (one) étudiant, ou de manière équivalent un (one) étudiant pour plusieurs (many) absences.

On se place prioritairement du coté du Many, et on doit écrire la relation ManyToOne. Elle est obligatoire pour définir la relation précédente.

Le code précédent est le minimum pour définir une relation.

On dit dans ce cas que Absence est propriétaire de la relation (toujours du coté du Many).

La relation décrite précédemment est unidirectionnelle. Pour la rendre bidirectionnelle il faut décrire la relation dans l'entité etudiant (avec la relation inverse OneToMany).

Le code de Absence devient

Le code de Etudiant sera :

La relation OneToMany n'est pas obligatoire. Elle permet juste d'inverser la relation, et de rendre la manipulation plus simple.

Dans ce cas, on fait apparaître un tableau ($this->absences), de type ArrayCollection contenant tous les objets associés à cette relation (many).

Relation 1..1 (OneToOne)

La relation 1..1 est peu utilisée mais permet une flexibilité en terme relationnelle très importante. Elle définit une dépendance unique entre 2 entités :

Utilisateur -> Adresse Produit -> Image Commande -> Facture

Relation N..N (ManyToMany)

Le fonctionnement est assez similaire à une relation ManyToOne/OneToMany, sauf que cette relation est forcément bidirectionnelle. Il faut décrire le comportement dans les deux entités et choisir, selon la logique désirée, qui sera la relation propriétaire (inversedBy) de la relation inverse (mappedBy).

Cette relation va créer une nouvelle table, contenant les deux clés étrangères.

Manipulation de la console

La console (make:entity), nous facilite la création des relations. En créant ou en modifiant l'entité, il est possible d'ajouter le champs contenant la relation. Pour cela le type sera "relation". La console vous demandera de préciser l'entité liée, ainsi que le type de relation. Vous pourrez ensuite selon la relation choisie, préciser la relation inverse, de manière optionnelle ou obligatoire.

Attention, il est d'usage de lancer la console dans l'entité qui porte la relation (propriétaire), ou l'entité qui recevra la clé étrangère.

Comme après chaque modification, il faudra générer le fichier de migration, et appliquer les modifications sur la base de données.

Exercice

• Créer la liaison entre Article et Categorie.

• Ajoutez deux catégories dans votre base de données et liées vos articles à l'une des catégories.

• Modifiez la page "/articles", pour afficher la catégorie de chacun des articles.

• Modifier la page "accueil" pour afficher les catégories (et toujours le dernier article publié).

• Créez une page "/categorie/..." pour afficher uniquement les articles de la catégorie.

  • On pourrait judicieusement utiliser un "include" pour avoir la présentation d'un article commune sur toutes les pages

• Faire fonctionner la recherche en utilisant les données du formulaire pour trouver et afficher les articles associés.

  • Modifier le repository de Article pour créer une méthode search($word)

    qui recherchera dans le titre et le contenu le mot $word

FORM

Introduction

La gestion des formulaire se fait via plusieurs classes PHP qui permettent entre autre :

• La structure et les propriétés du formulaire se gèrent via FormBuilder et peuvent être réutilisées;

• On peut créer des classes spécifiques pour chacun de nos formulaires

• Permet une gestion des validations simplifiée et une sécurité renforcée

• Permet d'hydrater une entité ou un objet rapidement

• Gestion de template simple

Pour pouvoir utiliser les formulaires, selon la version d'installation de Symfony, il peut être nécessaire d'installer les packages :

Pour les exemples ci-dessous, on considère l'entité suivante (exemple issue de la documentation Symfony) :

Création

On peut créer un Form de 2 façons différentes :

Directement dans un contrôleur

Cette première solution est rapide à mettre en place, et ne nécessite pas de fichier supplémentaire. Cependant, le formulaire ainsi créé n'est pas réutilisation dans d'autres méthodes.

Ou via des classes dédiées de type FormType en général dans le répertoire Form

Cette seconde solution, qui implique des fichiers complémentaires, permet une plus grande souplesse et une meilleure ré-utilisation dans d'autres contextes.

Le fichier ci-dessous permet de créer le même formulaire.

On utilise la classe FormBuilder accessible avec la méthode

dans un contrôleur ; l'argument $task est l'entité que vous souhaitez hydrater; l'argument n'est pas obligatoire (pour un formulaire de recherche par exemple)

On peut mettre des champs de formulaire par défaut en modifiant l'entité avant de créer le formulaire et de lier le formulaire à l'entité :

Par exemple

Pré-remplira le formulaire avec Ma tâche pré-définie.

Ensuite nous aurons des suites de ->add('nom_du_champs', TypeDeChamps::class, $options);

Par défaut si vous ne mettez que le nom du champs Symfony se chargera de récupérer un type de champs en fonction du type de champs (string, text, boolean, date, ...)

Dans une classe dédiée le createFormBuilder est déjà instancié il ne vous reste qu'à rajouter les différents add.

TWIG

Une fois le formulaire créé et initié il faut renvoyer le tout à TWIG via la méthode :

Soit par exemple

Ensuite nous aurons plusieurs fonctions twig utiles:

• {{ form }} permet d'afficher tout le formulaire

• {{ form_start }} permet de générer la balise <form> avec les différents attributs

• {{ form_end }} permet de générer la fermeture de <form> avec les différents champs restants non affichés

• {{ form_errors }} affiche les erreurs éventuelles du formulaire

• {{ form_widget(mon formulaire.nomduchamps) }} affiche le type de champs

• {{ form_label(mon formulaire.nomduchamps) }} affiche le label du champs

• {{ form_row(monformulaire.nomduchamps) }} affiche le form_widget et form_label

• {{ form_rest }} affiche les champs restants non récupéré précédemment (token de vérification par exemple)

Ces fonctions permettent une grande maîtrise de la mise en forme d'un formulaire. Cependant, elle implique de détailler les éléments.

Il est donc possible d'afficher un formulaire en une seule ligne, et le rendu dépendra du paramètrage (ou du template modèle) existant.

la variable_form correspond à la variable contenant le formulaire envoyée par le contrôleur. Il est enfin possible de préciser un "thème" pour votre formulaire avec la syntaxe :

Le template est un fichier twig qui vient préciser et définir pour chaque élément du formulaire (de manière globale), le rendu en HTML.

Action / Request

Une fois le formulaire créé et affiche via TWIG il faut rajouter un comportement qui va gérer la soumission du formulaire grâce à ces méthodes :

• handleRequest($request) permet d'associer les valeurs input à la classe Form précédemment créé

• isSubmitted() permet de savoir si le formulaire a été envoyé

• isValid() permet de savoir si les données saisies sont valides

Dans la majorité des cas on va tester si :

Validation

Ces contraintes ou assert peuvent être gérée de plusieurs façon XML, JSON, YAML, PHP ou en annotation dans notre cas; il faudra utiliser cette ligne tout en haut du contrôleur :

Pour ensuite pouvoir utiliser l'annotation :

Ici on vérifiera que le champs name doit être rempli.

Exercice

• Créer un formulaire directement dans CategorieController qui gèrera la création des Categories

• Modifier la page de listing des catégories pour rajouter un lien édition et suppression

• Mettre en place les différentes routes pour le "backoffice" de Categorie (ajout / modification / suppression / visualisation)

• Déporter le formulaire de gestion de Categorie vers une classe dédiée Form/CategorieType.php

• Modifier CategorieController pour utiliser CategorieType

• Ajouter une validation au formulaire sur le titre qui ne doit pas dépasser 150 caractères

• Rechercher pour mettre en place le template bootstrap pour les Form

• Gérer les autres routes : modification et suppression

Génération de CRUD

Ce que nous venons de faire manuellement peut être généré en ligne de commande par Symfony via la commande :

On vous demandera le nom de l'entité précédé du nom de bundle, le chemin pour ce crud et si vous souhaitez avoir les fonction d'édition (ajout/ modification) mettez oui.

On peut également générer seulement les FormType :

Attention si vous modifier une entité les FormType ne sont pas générés automatiquement il faudra rajouter manuellement le champs fraichement créé.

Exercice

• Générer le CRUD de Article

• Tester le fonctionnement, comprendre pourquoi ca ne fonctionne pas et corriger

• Mettre les liens dans le menu pour aller sur le listing post et listing postcategory; mettre en actif si url courante

Exercice 1

Créer un nouveau projet Symfony et installer les dépendances nécessaires.

Pour rappel, en ligne de commande depuis Docker/serveur et dans le repertoire où vous souhaitez mettre votre projet :

symfony new nomDuProjet --webapp

En utilisant la notion d'héritage des templates créez un menu avec 3 items :

• Accueil (qui mènera vers /)

• Articles (qui mènera vers /articles)

• Recherche (qui mènera vers /recherche)

Chaque page sera associée à une méthode dans un controller différent.

En utilisant les assets installer Bootstrap.

Sur la page accueil insérez une image de votre choix

Sur la page articles, ajouter des articles dans votre méthode de controller (dans un tableau associatif, ajouter au moins 3 articles).

Affichez ces 3 articles dans votre page articles.

Dans la page recherche, ajoutez simplement un formulaire de recherche comme vous l'auriez fait en BUT1.

Soignez un minimum la mise en page.

Pour la page recherche, on va simuler la récupération de la recherche utilisateur. Pour le moment, on a pas de source de donner pour effectuer la recherche.

Récupéré la recherche de l'utilisateur soumise avec un formulaire en method post ($request peut vous aider), et afficher dans une nouvelle page le mot recherché.

Vous veillerez à ce que le bon item soit "actif" dans le menu.

Introduction

Deux notions majeures interviennent dans la conception de sécurité de Symfony :

• Authentification : Qui êtes vous ? ; vous pouvez vous authentifier de plusieurs manières (HTTP authentification, certificat, formulaire de login, API, OAuth etc)

• Authorization : Avez vous accès à ? ; permet d'autoriser de faire telle ou telle action ou accéder à telle page sans forcément savoir qui vous êtes, utilisateur anonyme par exemple.

Pour fonctionner, il est nécessaire d'ajouter le composant security à votre symfony.

composer require symfony/security-bundle

La sécurité dans symfony implique plusieurs éléments :

• Le firewall: qui est la porte d'entrée pour le système d'authentification, on définit différents firewall (au minimum 1 seul) qui va permettre de mettre en place le bon système de connexion pour l'url spécifiée via un pattern.

• Le provider : qui permet au firewall d'interroger une collection d'utilisateurs/mot de passe ; C'est une sorte de base de tous les utilisateurs avec les mots de passe. Il existe deux type par défaut :

  • in memory : directement dans le fichier security.yml mais du coup les hash des mots de passes sont disponible dans un fichier

  • Entity : N'importe quelle entité qui implémente à minima les deux interfaces

    Copier

    use Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface;
    use Symfony\Component\Security\Core\User\UserInterface;

  • Enfin, plusieurs providers peuvent fonctionner en même temps par exemple in_memory et entity voire plusieurs entités simultanément. http://symfony.com/doc/current/security/entity_provider.html

• Un encoder : qui permet de générer des hashs/d'encoder des mots de passe ; le plus connu étant MD5 mais vous pouvez utiliser d'autres encoders tels que : sha1, bcrypt ou plaintext (qui n'encode rien c'est le mot de passe en clair) http://symfony.com/doc/current/security/named_encoders.html

• Les rôles : qui permettent de définir le niveau d'accès des utilisateurs connectés (authentifiés) et de configurer le firewall en fonction de ces rôles. Les rôles peuvent être hierarchisées afin d'expliquer par exemple qu'un administrateur (ROLE_ADMIN par exemple) et avant tout un utilisateur (ROLE_USER).

• Le "guard" ou "authenticator" qui va gérer l'authentification, au travers de "passport". Il va par exemple vérifier que le couple login/mot de passe existe dans l'un des provider.

Configuration

A partir de la version 4, et avec le composant "maker", la gestion de la sécurité a été grandement facilitée. Là où sur les précédentes versions (la 2 notamment), il était d'usage de passer par un bundle tierce (FOSUserBundle par exemple), aujourd'hui cela n'est plus nécessaire.

Créer sa classe User

Si vous ne disposez pas encore d'une classe permettant la gestion des utilisateurs, il est possible d'en créer une avec la console. Si vous disposez déjà d'une classe utilisateur (ou que vous souhaitez utiliser plusieurs entités, il faudra modifier votre code en implémentant les interfaces UserInterface, PasswordAuthenticatedUserInterface et en implémentant les méthodes imposées par ces interfaces).

L'instruction ci-dessous permet de lancer la console pour créer la table User.

bin/console make:user

Symfony va vous poser plusieurs questions afin de configurer les éléments (le nom de l'entité, si vous utilisez doctrine, le champ correspondant au login, et l'encodage du password.

bin/console make:user                                                                                                    davidannebicque@MacBook-Pro-de-David-2

 The name of the security user class (e.g. User) [User]:
 > 

 Do you want to store user data in the database (via Doctrine)? (yes/no) [yes]:
 > 

 Enter a property name that will be the unique "display" name for the user (e.g. email, username, uuid) [email]:
 > 

 Will this app need to hash/check user passwords? Choose No if passwords are not needed or will be checked/hashed by some other system (e.g. a single sign-on server).

 Does this app need to hash/check user passwords? (yes/no) [yes]:
 > 

 created: src/Entity/User.php
 created: src/Repository/UserRepository.php
 updated: src/Entity/User.php
 updated: config/packages/security.yaml

           
  Success! 
           

 Next Steps:
   - Review your new App\Entity\User class.
   - Use make:entity to add more fields to your User entity and then run make:migration.
   - Create a way to authenticate! See https://symfony.com/doc/current/security.html

Une fois cette commande exécutée vous avez un fichier d'entité de créé, un repository associé, et le fichier security.yaml (dans config) qui a été mis à jour.

Le fichier entité

<?php

namespace App\Entity;

use App\Repository\UserRepository;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface;
use Symfony\Component\Security\Core\User\UserInterface;

#[ORM\Entity(repositoryClass: UserRepository::class)]
class User implements UserInterface, PasswordAuthenticatedUserInterface
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 180, unique: true)]
    private ?string $email = null;

    #[ORM\Column]
    private array $roles = [];

    /**
     * @var string The hashed password
     */
    #[ORM\Column]
    private ?string $password = null;

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getEmail(): ?string
    {
        return $this->email;
    }

    public function setEmail(string $email): self
    {
        $this->email = $email;

        return $this;
    }

    /**
     * A visual identifier that represents this user.
     *
     * @see UserInterface
     */
    public function getUserIdentifier(): string
    {
        return (string) $this->email;
    }

    /**
     * @see UserInterface
     */
    public function getRoles(): array
    {
        $roles = $this->roles;
        // guarantee every user at least has ROLE_USER
        $roles[] = 'ROLE_USER';

        return array_unique($roles);
    }

    public function setRoles(array $roles): self
    {
        $this->roles = $roles;

        return $this;
    }

    /**
     * @see PasswordAuthenticatedUserInterface
     */
    public function getPassword(): string
    {
        return $this->password;
    }

    public function setPassword(string $password): self
    {
        $this->password = $password;

        return $this;
    }

    /**
     * @see UserInterface
     */
    public function eraseCredentials()
    {
        // If you store any temporary, sensitive data on the user, clear it here
        // $this->plainPassword = null;
    }
}

Le fichier security.yaml

Ce fichier fait le lien avec l'entité User (le provider), le login retenu (ici un email), et l'encodage du mot de passe, par défaut "auto"

security:
    # https://symfony.com/doc/current/security.html#registering-the-user-hashing-passwords
    password_hashers:
        Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'auto'
    # https://symfony.com/doc/current/security.html#loading-the-user-the-user-provider
    providers:
        # used to reload user from session & other features (e.g. switch_user)
        app_user_provider:
            entity:
                class: App\Entity\User
                property: email
    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false
        main:
            lazy: true
            provider: app_user_provider

            # activate different ways to authenticate
            # https://symfony.com/doc/current/security.html#the-firewall

            # https://symfony.com/doc/current/security/impersonating_user.html
            # switch_user: true

    # Easy way to control access for large sections of your site
    # Note: Only the *first* access control that matches will be used
    access_control:
        # - { path: ^/admin, roles: ROLE_ADMIN }
        # - { path: ^/profile, roles: ROLE_USER }

when@test:
    security:
        password_hashers:
            # By default, password hashers are resource intensive and take time. This is
            # important to generate secure password hashes. In tests however, secure hashes
            # are not important, waste resources and increase test times. The following
            # reduces the work factor to the lowest possible values.
            Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface:
                algorithm: auto
                cost: 4 # Lowest possible value for bcrypt
                time_cost: 3 # Lowest possible value for argon
                memory_cost: 10 # Lowest possible value for argon

Mise à jour de la BDD

Il faut ensuite mettre à jour votre base de données, avec les commandes suivantes:

bin/console d:s:u -f

#ou

bin/console make:migration
bin/console doctrine:migrations:migrate

Créer la partie connexion

Une nouvelle fois la console va nous permettre de dégrossir le travail et produire le contrôleur, le fichier de configuration et le formulaire de connexion.

bin/console make:auth

Pour le résultat ci-dessous.

bin/console make:auth                                                                                                    davidannebicque@MacBook-Pro-de-David-2

 What style of authentication do you want? [Empty authenticator]:
  [0] Empty authenticator
  [1] Login form authenticator
 > 1

 The class name of the authenticator to create (e.g. AppCustomAuthenticator):
 > LoginAuthenticator

 Choose a name for the controller class (e.g. SecurityController) [SecurityController]:
 > 

 Do you want to generate a '/logout' URL? (yes/no) [yes]:
 > 

 created: src/Security/LoginAuthenticator.php
 updated: config/packages/security.yaml
 created: src/Controller/SecurityController.php
 created: templates/security/login.html.twig

           
  Success! 
           

 Next:
 - Customize your new authenticator.
 - Finish the redirect "TODO" in the App\Security\LoginAuthenticator::onAuthenticationSuccess() method.
 - Review & adapt the login template: templates/security/login.html.twig.