Les principales fonctionnalités du Symfony CLI sont:
- La création d'un projet Symfony:
symfony new --full my_project
- La création d'un mini projet Symfony (Microservice, console application ou API):
symfony new my_project
- L'utilisation de components:
composer require <components>
Le CLI est un wrapper. Il permet de:
- créer un projet
- lancer un serveur http
- gère la partie Cloud (le déploiement du Cloud)
- manipuler la console
- gérer la version de php
Source: https://symfony.com/download
Utiliser la commande pour voir les différentes versions de PHP disponibles sur la machine:
symfony local:php:list
Et si vous voulez lui forcer la version en un type particulier, mettez dans le dossier dans lequel vous voulez créer un fichier .php-version qui contiendra la version que vous voulez, par exemple :
8.0.1
Utiliser la commande:
make:entity ou php bin/console make:entity
Quelles relations existent entre les entités (Many To One/Many To Many/...) ? Faire un schéma de la base de données.
Imaginons une relation entre une table Utilisateur et une table Article:
- Chaque Article est relié à (possède) un seul Utilisateur.
- Chaque Utilisateur est relié à (peut avoir) plusieurs Articles.
- Chaque Article est relié à (possède) plusieurs Utilisateurs.
- Chaque Utilisateur est relié à (peut avoir) un seul Article.
- Chaque Article est relié à (possède) plusieurs Utilisateurs.
- Chaque Utilisateur est relié à (peut avoir) plusieurs Articles.
- Chaque Article est relié à (possède) un seul Utilisateur.
- Chaque Utilisateur est relié à (peut avoir) un seul Article.
Source: https://symfony.com/doc/current/doctrine/associations.html
Le fichier .env est un fichier qui contient les variables d'environnement. C'est notamment dans ce dernier qu'on renseigne la connexion à la base de données; et si on est dans un environnement de developpement ou de production. Attention, le fichier .env avec les informations sensibles ne doit pas être commit. Créé un fichier .env.local qui reprendre la syntaxe de .env, et entre les informations sensibles dans le .local. Ce fichier est bloqué par le .gitignore.
Le .env est un fichier qui contient les clés de configuration de l'application.
Il faut changer le connecteur de la base de données car les identidiants/mot de passe peuvent (et doivent) différer entre le travail fait en local, et le projet mis en production.
On change le connecteur à la base de données car par défaut, il utilise Postgre, alors que nous souhaitons utiliser SQLite.
Source: https://symfony.com/doc/current/configuration.html#config-dot-env
Les migrations permettent de faire du versionning sur la base de données. Chaque migration est enregistrée dans un dossier "migrations", qui contient les requêtes permettant d'ajouter, modifier ou supprimer des tables ou des colonnes.
La migration est un delta entre deux changements d'état de base de données. Cela permet de faire du versionning de la base de données (permet de revenir en arrière).
Si lors de la migration (avec la commande: php bin/console make:migration), les erreurs suivantes apparaissent:
In AbstractPostgreSQLDriver.php line 102: An exception occurred in driver: could not find driver.
Alors le php.ini de la version utilisée est male configuré. Pour cela, éditer le fichier php.ini, et décommenter les lignes suivantes:
- extension=pdo_pgsql
- extension=pdo_sqlite
- extension=pgsql
Copier le fichier .env et nommer cette copie ".env.local".
Dans .env.local, décommenter la ligne de DATABASE_URL utilisant le SQLite; et commenter les 2 autres (avec "#").
Enfin, on peut utiliser la commande php bin/console make:migration pour créer un fichier de migration (une version).
Pour lancer la migration (pour effectuer les modifications de la base de données avec les dernières versions):
php bin/console doctrine:migrations:migrate
- easyAdmin
- sonata
EasyAdmin permet de créer des pages d'administration back-end.
Installation:
composer require easycorp/easyadmin-bundle
C'est un bundle qui permet de rapidement créer une interface admin (back-office).
Source: https://symfony.com/doc/current/bundles/EasyAdminBundle/index.html
On doit implémenter des méthodes to string dans nos entités pour pouvoir les utiliser dans notre Dashboard. Par exemple pour la création d'un poste et qu'on doit choisir un utilisateur, cela appelera automatiquement la méthode toString.
public function __toString(): string
{
return $this->username();
}
Permet d'afficher une chaine de caractère au lieu de l'objet.
Un contrôleur ne devrait pas avoir plus de 5 méthodes Une méthode de contrôlleur ne devrait pas contenir plus de 20 lignes
php bin/console make:controller
En plus de créer le contrôleur avec une méthode d'index; cela créé un petit modèle de template.
Le ParamConverter permet de convertir les paramètres de la requête en objet.
Par exemple, avec une route "/edit/{id}" permet transformer l'id en un objet.
#[Route('/post/{id}/edit', name: 'post_edit')]
public function edit(Post $post, Request $request)
Post $post est le post d'id {id}.
Fonctionne aussi pour les dates.
Source: https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html
Un formulaire Symfony est un formulaire (dont chaque champ est lui même un form) qui reprend les champs d'une entité.
La commande pour créer un formulaire: php bin/console make:form
Un formulaire est un composant qui possède des champs.
{{ form_start(form) }} {{ form_errors(form.name) }} {# positionne le message d'erreur s'il y a #} {{ form_label(form.name) }} {# affiche le label #} {{ form_widget(form.name) }} {# affiche le champ #} {{ form_row(form.name) }} {# affiche le champ #}
{{ form_rest(form) }} {# affiche les champs restants #} {{ form_end(form) }}
Les formulaires Symfony sont facilement personnalisable.
On peut appliquer un thème:
- à un tous les formulaires;
- à un seul formulaire;
- à plusieurs formulaires.
Source: https://symfony.com/doc/current/form/form_themes.html
Source: https://symfony.com/doc/current/security.html
Encoder permet de chiffrer. C'est dans config/packages/security.yaml qu'on choisit dans quelle classe l'utiliser, et quel algorithme utiliser pour chiffrer.
Source: https://symfony.com/doc/current/security/named_encoders.html
Provider permet de gérer les sessions (garder l'utilisateur authentifié). Méthode qui permet de récupérer les utilisateurs en base.
Source: https://symfony.com/doc/current/security/user_provider.html
Le Firewall permet de restreindre l'accès à certaines informations. Ces restrictions peuvent se faire en fonction:
- d'un chemin;
- d'un hôte;
- d'une méthode HTTP;
- d'un service.
Permet de sécuriser une partie du site. Gère la sécurité en général.
Source: https://symfony.com/doc/current/security/firewall_restriction.html
L'access control permet de restreindre l'accès à certaines pages, notamment en fonction du rôle. Un exemple directement dans le Twig:
{% if is_granted('ROLE_ADMIN') %}
<a href="...">Delete</a>
{% endif %}
Gère l'accès à une page:
access-control:
- { path: ^/admin, roles: ROLE_ADMIN }
Que toutes les pages qui commencent par la route '/admin' nécessaites le role d'admin pour y accéder.
Source: https://symfony.com/doc/current/security/access_control.html Source: https://symfonycasts.com/screencast/symfony-security/access-control Source: https://symfony.com/doc/current/security.html#access-control-in-templates
Les rôles permettent de grouper des utilisateurs pour leur donner des droits et des restrictions (généralement pour accéder à des pages).
Un rôle est un privilège d'accès.
Source: https://symfony.com/doc/current/security.html#roles Source: https://symfony.com/doc/current/security.html#hierarchical-roles
Le voter permet de gérer les permissions. Il permet de sécuriser une page ou une action bien précises.
Source: https://symfony.com/doc/current/security/voters.html
FOSUserBundle est un bundle de Symfony qui premet de simplifier la gérance des utilisateurs. On ne l'utilise pas car on peut gérer les utilisateurs et les permissions sans ce bundle (et ainsi éviter une dépendance).
Source: https://symfony.com/doc/2.x/bundles/EasyAdminBundle/integration/fosuserbundle.html
Argon2 est une fonction de dérivation de clé. En d'autres termes, cela permet de crypter une chaine de caractère (mot de passe).
C'est le standard actuel.
*Source: https://fr.wikipedia.org/wiki/Argon2"
bcrypt est une fonction de hachage. En d'autres termes, cela permet de crypter une chaine de caractère (mot de passe).
Source: https://fr.wikipedia.org/wiki/Bcrypt
Plaintext signifie 'Text en clair'. Il est donc nécessaire de le changer par un algorithme de hachage. Exemple, passer de:
# config/packages/security.yaml
security:
# ...
encoders:
Symfony\Component\Security\Core\User\User: plaintext
# ...
en
# config/packages/security.yaml
security:
# ...
encoders:
Symfony\Component\Security\Core\User\User:
algorithm: bcrypt
cost: 12
Plaintext rend les chaines de caractères en clair dans la base de données (est une faille de sécuriser)
Source: https://symfony.com/doc/4.0/security.html#b-configuring-how-users-are-loaded
BasicHTTP permet de valider les authentifications HTTP. La fenêtre de dialogue d'un navigateur (un petit formulaire de connection directement dans une pop-up du navigateur)
Source: https://symfony.com/doc/current/security/auth_providers.html
Le hachage, c'est le fait de rendre une chaine de caractère non reconnaissable. Elle est changée en une autre chaine de caractère. Chiffrer un mot de passe permet d'éviter que les hébergeurs puissent lire le mot de passe en base de données.
Hacher n'est pas decriptable. On enregistre le hache du mot de passe de l'utilisateur lors de son inscription. Lors de sa connection, on compare le hache de son mot de passe entré et le hache enregistré dans la base de données.
Source: https://fr.wikipedia.org/wiki/Fonction_de_hachage
Pour créer un formulaire d'authentification, utiliser la commande suivante:
php bin/console make:auth
Source: https://symfony.com/doc/current/security/form_login_setup.html
Faire un schema expliquant quelle méthode est appelée dans quel ordre dans le LoginFormAuthenticator . Définir l'objectif de chaque méthodes du fichier.
La méthode supports vérifie que l'utilisateur envoie une demande d'authentification provenant de la page de login (app_login) et que la requête est bien de type POST.
Si la méthode supports retourne false, alors le processus d'authentification s'arrête. En revanche, si elle retourne true, alors il appelle la méthode getCredentials. Cette dernière retourne l'username, le mot de passe et un token.
A partir des informations récupérées depuis la fonction getCredentials, la méthode getUser permet de retourner un Utilisateur (ou null si n'est pas trouvé; dans ce cas, le processus d'authentification est arrêté).
Si la méthode getUser trouve un Utilisateur, alors la méthode checkCredentials est appelée à son tour. Cette dernière permet de vérifier si le mot de passe (ou d'autres informations) est correcte. Si elle retourne true, alors l'utilisateur s'authentifie, sinon le processus d'authentification s'arrête.
Stock la route sur laquelle vous êtiez avant la connexion. C'est elle qui authentifie l'utilisateur, et renvoit sur le chemin précédent la connexion.
Source: https://symfonycasts.com/screencast/symfony-security/login-form-authenticator
Pour créer un formulaire d'inscription, il faut utiliser la commande: php bin/console make:registration-form
Définition des termes suivants:
Un service est une classe dans laquelle on dépose des méthodes qui permettent de retravailler nos objets. Ce sont des méthodes qui peuvent être réutilisées partout dans le projet. Les services permettent notamment d'arranger l'architecture de l'application.
Le controller, le repository sont des services. Toutes les classes du projet sont des services. Les services sont centrals pour le projet de Symfony.
Source: https://symfony.com/doc/current/service_container.html
Une injection de dépendance, c'est-à-dire passer un object à un autre. De ce fait, on peut avoir un service qui comprend d'autres services à sa création, et donc sont accessibles depuis ce premier.
Le composant DependencyInjection implémente un conteneur de services compatible qui vous permet de standardiser et de centraliser la façon dont les objets sont construits dans votre application. Le composant DependencyInjection implémente un conteneur de services compatible PSR-11 qui vous permet de standardiser et de centraliser la façon dont les objets sont construits dans votre application.
Source: https://symfony.com/doc/current/components/dependency_injection.html Source: https://stackoverflow.com/questions/130794/what-is-dependency-injection
L'autowiring permet de passer automatiquement le bon service dans chaque méthode en lisant les informations du constructeur. L'autowiring vous permet de gérer les services dans le container avec une configuration minimale.
Capacité à appeler une classe depuis le paramètre d'une méthode.
Source: https://symfony.com/doc/current/service_container/autowiring.html
Un Container permet de rendre un service plus flexible, en y proposant le choix des arguments. Exemple avec une classe Mailer:
class Mailer
{
private $transport;
public function __construct($transport)
{
$this->transport = $transport;
}
// ...
}
On peut créer un container et y choisir le transport (sendmail):
use Symfony\Component\DependencyInjection\ContainerBuilder;
$containerBuilder = new ContainerBuilder();
$containerBuilder
->register('mailer', 'Mailer')
->addArgument('sendmail');
Le container est un registre de tous les services disponibles.
Source: https://symfony.com/doc/current/service_container.html Source: https://symfony.com/doc/current/components/dependency_injection.html
Les validateurs permettent de donner des contraintes sur des champs de formulaire. On les écrits directement dans la classe de l'entité pour avoir une validation qui se fait dans le back. Ainsi, on ne peut pas retirer les contraintes avec l'inspecteur. Cela permet d'éviter que des utilisateurs entrent n'importe quoi dans la base de données.
On peut valider les données lors de la création ou la modification d'un objet.
Installation avec: composer require symfony/validator doctrine/annotations
Pour ajouter une condition demandant à ce que le champ ne soit pas nul, il faut utiliser dans l'entité:
use Symfony\Component\Validator\Constraints as Assert;
Puis, en dessus de l'attribut choisis, ajouter la condition:
@Assert\NotBlank
Attention, il ne faut pas oublier de rendre nullable le mutateur du champ en ajoutant un '?'. Exemple:
public function setTitle(?string $title): self
{
$this->title = $title;
return $this;
}
Permet de valider les données qui sont dans le formulaire. Il gère les messages d'erreur (traduit).
Par exemple, dans le cas d'un utilisateur, on peut souhaiter que l'username soit unique.
Pour cela, il faut utiliser dans l'entité souhaitée:
use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;
et renseigner en dessus de la classe:
@UniqueEntity(fields={"username"}, message="There is already an account with this username")
Source: https://symfony.com/doc/current/validation.html
Les différentes parties du Serializer sont: ObjectNormalizer : utilise le composant pour accéder aux propriétés de l’objet. Cherche les propriétés public de l’objet, cherche toutes les méthodes public ayant en nom get/set/has/is/add/remove suivi d’un nom de propriété ainsi que les méthodes magiques. GetSetMethodNormalizer : utilise les getter/setter de l’objet. Cherche toutes les méthodes public ayant en nom get suivi d’un nom de propriété. PropertyNormalizer : utilise PHP reflexion pour accéder aux propriétés de l’objet. Cherche les propriétés public et private de l’objet.
Tout comme les normalizers, le composant Serializer inclut plusieurs encodeurs/decodeurs de format : JsonEncoder, XmlEncoder, YamlEncoder et CsvEncoder.-
Un serializer permet de transformer les données en chaines de caractères.
Les parties sont: L'encoder et le Normaliser. (et donc inversement le denormaliser et le decoder)
Source: https://www.novaway.fr/blog/tech/comment-utiliser-le-serializer-symfony
Permet de créer une API et génére une documentation.