Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Laravel
  3. Travailler avec les données
Extrait - Laravel Un framework efficace pour développer vos applications PHP (2e édition)
Extraits du livre
Laravel Un framework efficace pour développer vos applications PHP (2e édition) Revenir à la page d'achat du livre

Travailler avec les données

Sécuriser les formulaires

Utiliser des formulaires HTML est un moyen simple pour gérer les interactions entre un site et ses visiteurs. Un formulaire est cependant un vecteur d’attaque potentiel pour une personne malveillante. Laravel propose par défaut un mécanisme de défense face aux attaques de type CSRF (Cross-Site Request Forgery). Avant d’aller plus loin dans l’utilisation des formulaires, il est nécessaire de faire un point sur la sécurité.

1. Attaques CSRF

Une attaque CSRF a pour objet de transmettre une requête HTTP falsifiée à un utilisateur connecté pour qu’il l’exécute à son insu, avec ses propres droits. Si cet utilisateur est administrateur et que le site n’est pas protégé contre cette faille, l’attaquant pourra bénéficier de l’ensemble des droits de cet utilisateur pour réaliser les actions qu’il souhaite.

Pour en apprendre plus sur les attaques CSRF : https://fr.wikipedia.org/wiki/Cross-Site_Request_Forgery

2. Fonctionnement du CSRF Token

Lorsqu’un utilisateur se rend sur une page de notre application web, Laravel génère automatiquement une session et lui associe un jeton de sécurité (appelé CSRF Token). Ce jeton de sécurité est utilisé pour vérifier que l’utilisateur est bien celui qui envoie...

Valider les données

1. Introduction

Les données d’une application web proviennent généralement de ses propres formulaires, mais il est courant que d’autres sources de données existent (plateformes de données ouvertes, APIs, etc.). Dans tous les cas, nous n’avons pas le contrôle sur la façon dont les données vont être produites. Un utilisateur peut passer outre la validation d’un formulaire défini côté client, tout comme un fournisseur de données peut changer du jour au lendemain le format de ses données. L’étape de validation protège l’application web contre ces risques. Les bénéfices sont multiples et le temps investi à rédiger des règles de validation est souvent largement rentabilisé : moins de comportements inattendus de l’application, assurance de la qualité des données, réduction des possibilités d’exploiter une vulnérabilité.

Le framework Laravel nous fait gagner énormément de temps en mettant à disposition une centaine de règles de validation qui permettent de couvrir la plupart des besoins d’une application web. En une ligne de code, il est possible de valider le format d’une adresse e-mail et de s’assurer qu’elle n’existe pas encore dans notre base de données !

La logique de validation peut être incluse dans les contrôleurs ou dans une classe dédiée de type form request.

2. Validation dans le contrôleur

a. Contexte

Un usage classique dans une application web est de créer du contenu à partir d’un formulaire HTML. Dans un premier temps, il faut afficher ce formulaire côté client, le valider côté serveur et enregistrer le contenu dans la base de données pour enfin renvoyer un message de succès ou d’erreur.

Dans une application Laravel, cela se traduit au minimum par :

  • un modèle avec son fichier de migration associé pour l’enregistrement dans la base de données,

  • un contrôleur pour l’affichage des différentes vues, la validation et l’enregistrement du modèle,

  • trois routes : affichage du formulaire, soumission du formulaire et en cas de succès, redirection vers...

Formulaires PATCH, PUT et DELETE

Une API REST doit utiliser les méthodes HTTP adaptées. Par exemple, pour répondre à une action de suppression d’une ressource, nous utiliserons la méthode DELETE plutôt que la méthode POST.

Les formulaires HTML ne prennent pas en charge les actions PUT, PATCH ou DELETE. Ainsi, lors de la définition de routes PUT, PATCH ou DELETE appelées à partir d’un formulaire HTML, il faut ajouter un champ _method masqué au formulaire. La valeur envoyée avec le champ _method sera utilisée comme méthode de requête HTTP.

Laravel fournit pour cela la directive blade @method qui crée automatiquement un champ input caché avec la valeur souhaitée. Pour l’illustrer, ajoutons la possibilité de supprimer un article.

Fichier resources/views/articles/index.blade.php

<h1>Liste des articles</h1> 
 
<!--Affichage du succès de création/suppression d'un article --> 
@if (session('message')) 
    <div>{{ session('message') }}</div> 
@endif 
 
@foreach($articles as $article) 
 
    <div> 
 
        <p>{{ $article->title }}</p> 
 
        <form...

Chargement de fichiers

1. Configuration

Pour la gestion de fichiers côté serveur, la configuration s’établit en déclarant une liste de disques, ce qui offre la possibilité de jongler entre différents emplacements de stockage. Les disks sont déclarés et configurés dans le fichier config/filesystems.php qui est configuré par défaut avec les disques local et public.

Disques déclarés par défaut, fichier config/filesystems.php

'default' => env('FILESYSTEM_DISK', 'local'), 
 
'disks' => [ 
 
    'local' => [ 
        'driver' => 'local', 
        'root' => storage_path('app'), 
        'throw' => false, 
    ], 
 
    'public' => [ 
        'driver' => 'local', 
        'root' => storage_path('app/public'), 
        'url' => env('APP_URL').'/storage', 
        'visibility' => 'public', 
        'throw' => false, 
 
    ], 
 
],  

Le disque local est déclaré en tant que disque à utiliser par défaut pour toutes les opérations de stockage via l’attribut default du fichier de configuration filesystems.php. Les différentes méthodes de Laravel effectuant les opérations de stockage ont toujours un paramètre optionnel permettant de choisir le disque à utiliser.

Tout comme...