16 - Symfony : Validation

Objectifs

• ✅ Écrire une validation dans Symfony
• ✅ Découvrir les différentes contraintes existantes
• ✅ Exécuter la validation

Pré-requis

​ Avoir terminé la quête

Introduction

Lorsque des données proviennent d’un utilisateur (URL, soumission de formulaire…), il faut toujours vérifier l’intégrité des données côté serveur.

Ne fais jamais confiance à l’utilisateur, jamais, JAMAIS ! Et ce pour n’importe quel type d’utilisateur (visiteur, administrateur ou même toi).

Sinon, un jour ou l’autre, de manière volontaire ou par inadvertance, tu auras des problèmes (données tronquées, injection SQL…)

Résumé : les données de l’utilisateur, à qui on ne fait JAMAIS confiance, doivent TOUJOURS être vérifiées côté SERVEUR.

Sommaire

🕵️‍♀️ Validations dans Symfony, comment cela se passe-t-il ?

Dans Symfony, les vérifications des données côté serveur se font via un composant dédié à la validation (le composant Validator), installé par défaut par le website-skeleton (option --webapp de l’installateur Symfony). Ce composant permet d’écrire des validations rapidement, de gérer des messages d’erreur adaptés et est facilement extensible pour des cas plus complexes. Le composant formulaire de Symfony est directement lié à ce dernier et permet également d’afficher sans effort les éventuelles erreurs dans la vue du formulaire.

Il est possible de configurer les validations de différentes manières. Tu vas te servir à nouveau des attributs que tu commences à bien connaître puisque que tu les as déjà utilisés pour les routes ou pour Doctrine.

Ces attributs vont être écrits dans tes fichiers d’Entity (c’est assez logique, puisque les entités caractérisent tes données). Il faut tout d’abord faire un use Symfony\Component\Validator\Constraints as Assert. Pour rappel, le as permet de donner un alias (ici Assert) qui sera utilisé dans l’attribut. Cette dernière est sous la forme #[Assert\TypeDeContrainte()] et se place au-dessus d’une propriété dans la classe. Il existe un grand nombre de contraintes pré-disponibles dans Symfony, pour tester si la donnée n’est pas vide, sa longueur, son type, etc.

Par exemple, ici :

use Symfony\Component\Validator\Constraints as Assert;

class Category
{
    #[Assert\NotBlank]
    public $name;

    //...
}

Ici, la contrainte NotBlank permet de vérifier qu’une valeur associée à la propriété name d’un objet de type Category n’est pas "vide". En ajoutant cette contrainte, si l’utilisateur outrepasse les validations côté client, il ne passera pas la méthode ->isValid() que tu utilises dans le controller.

Il est bien entendu possible (et souvent nécessaire) de cumuler plusieurs #[Assert]. En effet, il est également intéressant ici de tester la longueur maximale du champ. De plus, si la propriété est reliée à une table de base de données via Doctrine, les attributs de type #[ORM] seront également présents. Voici un exemple plus complet :

use Symfony\Component\Validator\Constraints as Assert;
use Doctrine\ORM\Mapping as ORM;


#[ORM\Entity(repositoryClass: CategoryRepository::class)]
class Category
{
    #[ORM\Column(length: 255)]
    #[Assert\NotBlank]
    #[Assert\Length(max: 255)]
    private $name;
}

Les contraintes possèdent également des paramètres (optionnels ou non, en fonction des cas). Par exemple, NotBlank peut rester sans paramètre, tandis que Length demandera au moins de lui indiquer une taille minimum ou maximum.

Chaque contrainte affiche un message d’erreur par défaut (en anglais). Il est parfois utile de le personnaliser. Pour ce faire, il faut utiliser le paramètre correspondant. Il est possible d’y afficher la valeur actuelle erronée, via le placeholder {{ value }}, ainsi que la valeur ou contrainte attendue (si cela est pertinent), via {{ limit }}.

#[ORM\Column(length: 255)]
#[Assert\NotBlank(message: 'Ne me laisse pas tout vide')]
#[Assert\Length(
    max: 255,
    maxMessage: 'La catégorie saisie {{ value }} est trop longue, elle ne devrait pas dépasser {{ limit }} caractères',
)]
private $name;

Chaque contrainte a ses propres options. Length, par exemple, permet de configurer un message d’erreur différent pour un dépassement de la taille minimale ou de la taille maximale. Il faut se référer plus en détail à la documentation de chaque contrainte pour correctement les paramétrer.

🚷 Les différentes contraintes

Tu sais maintenant comment configurer les contraintes. Il en existe actuellement une cinquantaine, et Symfony en ajoute régulièrement de nouvelles. Elles te permettent de répondre à la grande majorité des besoins en termes de vérification de données. Sache juste qu’il est également possible de configurer des contraintes personnalisées plus complexes, si besoin, même si cela ne sera pas détaillé ici.

Ces contraintes sont toutes listées sur la documentation officielle. Elles sont organisées en plusieurs catégories, voici quelques exemples (non exhaustifs) :

• Contraintes basiques : vérification d’existence d’une valeur (null ou vide), vérification du type d’une valeur (string, int…)

• Contraintes sur les chaînes de caractères : tests sur les longueurs, vérification sur les formats (email, url, adresse IP) ou personnalisée via la contrainte Regex permettant de définir une expression régulière.

• Contraintes de comparaison : vérification si la valeur saisie est égale, différente, plus grande ou plus petite qu’une valeur attendue.

• Contraintes de Date : test si la valeur est bien de format date (ou datetime ou time).

• Contraintes de Choix : test si la valeur fait partie d’une liste préétablie par le développeur, ou de listes préconfigurées dans Symfony (liste des pays, des langues, des devises, etc.) correspondant à certains standards ISO.

• Contraintes sur les fichiers : utile pour l’upload notamment. Sert à vérifier si un fichier a la bonne extension, ne dépasse pas la taille requise. Il existe même des contraintes propres aux fichiers images, sur la taille de l’image en pixels, son ratio, etc.

• Contraintes financières : vérifie si la valeur correspond bien à un format de code BIC, de carte bleue, IBAN, etc. Utile pour du paiement en ligne, par exemple.

• Autres contraintes : vérifier l’unicité d’une valeur, créer des contraintes personnalisées, etc.

Lancer la validation

Le composant formulaire de Symfony est lié au composant validator. De ce fait, il est extrêmement facile de valider un formulaire en fonction des contraintes écrites dans l’Entity. Pour cela, il suffit d’utiliser la méthode isValid() du formulaire.

// $form initialization

if ($form->isSubmitted() && $form->isValid()) {
    // handle data, in example, an insert into database
    // redirection
}

// form rendering

La méthode isValid() retourne un booléen. Elle doit être appelée au moment de la soumission du formulaire et juste après $form->isSubmitted(). En effet, il est logique de ne valider les données d’un formulaire qu’une fois celles-ci soumises.

Sur l’exemple de code ci-dessus, si le formulaire n’est pas valide, ni l’insertion en base de données, ni la redirection ne sont effectuées et le formulaire est donc ré-affiché. Cependant, dans ce cas, les erreurs vont être récupérées automatiquement dans le formulaire et apparaître à l’écran (l’helper Twig {{ form_errors() }} permet d’en personnaliser l’affichage).

Pour résumer, lorsque tu crées un formulaire relié à une entité, il suffit de configurer correctement les contraintes dans la classe d’entité, et l’appel de $form->isValid() permet d’assurer la cohérence des données saisies par l’utilisateur, et d’afficher les éventuelles erreurs.

💪 Challenge

Validation d’une série

Dans la quête, tu as vu des exemples pour configurer une validation sur les catégories. Maintenant, il faut que tu prennes le reflexe d’ajouter systématiquement des contraintes de validation sur tous les champs de toutes tes entités qui en ont besoin. Dans le cadre du challenge, tu vas configurer ton entité Program afin qu’elle suive ces règles simples de validation :

• le champ title ne doit pas être vide et doit faire moins de 255 caractères
• le champ title doit être unique. Si le titre existe déjà en base de données, le message "ce titre existe déjà" doit apparaître. Regarde du côté de la contrainte UniqueEntity (qui a la particularité de se configurer au niveau de la classe et non d’une propriété)
• le champ synopsis de la série ne doit pas être vide
• [BONUS 🤩 ] le champ synopsis ne doit pas contenir la chaîne "plus belle la vie", sinon le message d’erreur "On parle de vraies séries ici" apparaît. Regarde en détail les options de la contrainte "Regex" pour t’aider.

Ton formulaire d’ajout de programme doit effectuer les vérifications de validation. S’il y a des erreurs, les messages correspondants doivent s’afficher.

Poste une branche "validation" sur ton repository Github et prends une vidéo montrant le bon fonctionnement de ces validations (dans lequel on verra les messages d’erreur appropriés s’afficher) et poste un lien vers la vidéo dans le README.

🧐 Critères de validation

• Une erreur appropriée apparaît au niveau de ton formulaire si un titre vide ou un titre supérieur à 255 caractères est envoyé au serveur.
• Le message "ce titre existe déjà" doit apparaître dans ton formulaire, si le titre saisi existe déjà pour une autre série
• Une erreur appropriée apparaît au niveau de ton formulaire si un synopsis vide est envoyé au serveur.
• [Bonus] Si le summary de la série contient le texte "plus belle la vie", le message d’erreur "On parle de vraies séries ici" apparaît à la place.
• Le code est disponible sur Github.