Frameworks PHP : erreurs cachées à éviter

Les frameworks tels que Symfony (7.2 au moment de la rédaction) ou Laravel sont hautement personnalisables et encouragent les bonnes pratiques, quelles que soient votre expérience et vos compétences.

Cependant, vous pouvez toujours introduire des problèmes de conception, de sécurité ou de performances.

Symfony : n'appelez pas directement le $container

❌ Celui-ci est un classique mais toujours très utilisé par les développeurs :

 class LuckyController extends AbstractController
  {
      public function index()
       {
        $myDependency = $this->container->get(MyDependencyInterface::class);
        // 
       }

C'est possible car le AbstractController parent définit $container comme protégé :

protected ContainerInterface $container;

Source : Symfony - GitHub

Bien que cela fonctionne, c'est une mauvaise pratique pour diverses raisons :

• ça nuit à la lisibilité
• c'est plus difficile à tester
• il s'appuie sur des états globaux ($container)
• cela pourrait entraîner des problèmes d'incompatibilité à l'avenir, à mesure que Symfony évolue

✅ Utilisez plutôt l'injection de dépendances dans le constructeur :

 class LuckyController extends AbstractController
  {
      public function __construct(private MyDependencyInterface $myDependency) {}

ORM éloquent : n'utilisez pas aveuglément les requêtes brutes

Eloquent permet d'écrire des requêtes SQL de manière très pratique.

Au lieu d'écrire directement des requêtes SQL, les développeurs peuvent utiliser des wrappers PHP pour interagir avec les entités de base de données.

Il utilise également des liaisons SQL en arrière-plan, vous bénéficiez donc d'une protection contre les injections gratuitement, même avec des entrées non fiables :

User::where('email', $request->input('email'))->get();

❌ Cependant, lorsque vous utilisez des assistants comme WhereRaw, vous pouvez introduire des vulnérabilités :

User::whereRaw('email = "'. $request->input('email'). '"')->get();

✅ Au moins, toujours utilisez les liaisons SQL :

User::whereRaw('email = :email', ['email' => $request->input('email')])->get();

N.B. : l’exemple ci-dessus n’a pas de sens, mais il simplifie les choses. Dans des cas d'utilisation réels, vous aurez peut-être besoin dewhereRaw à des fins d'optimisation ou pour implémenter des conditions Where très spécifiques.

Laravel : qu'en est-il du CSRF ?

Avec les attaques CSRF, les pirates informatiques forcent les utilisateurs finaux à exécuter des actions indésirables sur une application dans laquelle ils sont actuellement authentifiés.

Laravel dispose d'un mécanisme intégré pour se prémunir contre un tel scénario.

En gros, il ajoute un jeton (champ caché) à envoyer avec vos demandes, afin que vous puissiez vérifier que "l'utilisateur authentifié est la personne qui fait réellement les demandes à l'application."

Assez juste.

❌ Cependant, certaines applications ignorent cette implémentation.

✅ La question de savoir si vous devez utiliser le middleware intégré n'est pas pertinente ici, mais assurez-vous que votre application est sécurisée contre les attaques CSRF.

Vous pouvez lire cette page pour plus de détails sur l'implémentation dans Laravel.

Veuillez également sécuriser les requêtes AJAX.

ORM éloquent : les requêtes ne sont pas optimisées « automatiquement »

Eloquent permet un chargement rapide/paresseux et prend en charge diverses optimisations, telles que la mise en cache des requêtes, l'indexation ou le traitement par lots.

Cependant, cela n’empêche pas tous les problèmes de performances, notamment sur les grands ensembles de données.

❌ Il n'est pas rare de voir de telles boucles :

 class LuckyController extends AbstractController
  {
      public function index()
       {
        $myDependency = $this->container->get(MyDependencyInterface::class);
        // 
       }

Mais cela peut entraîner des problèmes de mémoire.

✅ Lorsque cela est possible, une meilleure approche exploiterait les collections et les aides Laravel comme chunk :

protected ContainerInterface $container;

Consultez la documentation pour plus de détails.

N.B. : Cela fonctionne, mais n'oubliez pas que ces assistants sont uniquement destinés à faciliter la mise en œuvre, vous devez donc surveiller les requêtes lentes et autres goulots d'étranglement.

Symfony : services SRP

Comme le dit la documentation :

les objets utiles sont appelés services et chaque service vit à l'intérieur d'un objet très spécial appelé conteneur de services. Le conteneur permet de centraliser la manière dont les objets sont construits. Cela vous facilite la vie, favorise une architecture solide et est super rapide !

En d'autres termes, vous rédigerez des services personnalisés pour gérer des responsabilités spécifiques pour votre application.

❌ La documentation est exacte. Il vise à promouvoir une architecture solide, mais il n'est pas rare de lire des services qui enfreignent le principe de responsabilité unique (SRP) :

 class LuckyController extends AbstractController
  {
      public function __construct(private MyDependencyInterface $myDependency) {}

✅ Vous devez respecter ce principe. Ce sera plus facile à tester et à maintenir.

Symfony : services publics vs services privés

❌ Avec Symfony, vous pouvez utiliser $container->get('service_id') pour appeler n'importe quel service public.

Nous avons vu plus haut qu'appeler le $container ainsi est considéré comme une mauvaise pratique.

Vous ne résisterez peut-être pas à la tentation de rendre tous les services publics, vous pourrez donc les récupérer par leur identifiant presque partout dans le projet.

Ne fais pas ça.

✅ Au lieu de cela, gardez la plupart des services personnalisés privés et utilisez l'injection de dépendances.

Conclure

J'espère que vous éviterez ce que j'aime appeler des « erreurs latentes » ou des « erreurs cachées » avec les frameworks.

Si vous ne savez pas comment l'implémenter, faites confiance au framework, mais sachez que certains mécanismes peuvent ne pas être activés par défaut.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!