Quels sont les inconvénients de l'utilisation du code de filtrage PHP dans les blocs, les nœuds, les vues-arguments, etc.?

J'ai souvent vu des personnes dire de ne pas utiliser de filtres PHP / PHP personnalisés (à partir de l'interface utilisateur de Drupal) dans des blocs, des nœuds, des vues, des règles, etc. J'ai un peu cherché et je n'ai pas trouvé grand chose, il semble que C’est une pratique recommandée par Drupal que tous «connaissent».

Je comprends que cela pose un risque potentiel pour la sécurité, en particulier aux utilisateurs finaux ou aux nouveaux utilisateurs de Drupal ou de PHP, mais en tant que développeur / constructeur de site, quelles sont les vraies raisons de ne pas utiliser du PHP personnalisé à partir de l'interface utilisateur de Drupal?

Certaines raisons:

• Le code dans votre base de données ne peut pas être contrôlé par la version et est également plus difficile à trouver en général plus tard.
• Le code Eval () est beaucoup plus lent que quelque chose codé en dur dans un fichier.
• S'il y a une erreur quelque part dans ce code, vous obtiendrez un message d'erreur très peu utile (erreur dans le code eval () à la ligne 3) et vous devrez peut-être parcourir votre base de données manuellement pour rechercher et corriger l'erreur. S'il se trouve à l'intérieur d'un bloc affiché sur toutes les pages, il provoque une erreur fatale tout le temps, par exemple.
• Ce qui précède est également vrai lors de la mise à niveau de Drupal 6 à 7 et de toutes les API que vous avez utilisées ont été modifiées. Vous devrez donc porter votre code lors de la migration. Si le code est dans un module, vous pouvez le porter à l'avance, le tester et le déployer uniquement sur le nouveau site. À l'intérieur d'un nœud ou d'un bloc, cela ne fonctionnera qu'avec Drupal 6 ou 7.
• Écrire et maintenir ce code est également plus difficile, car vous travaillez dans un champ de texte dans votre navigateur. Avoir cela dans un module vous permet d'utiliser un éditeur / IDE avec la coloration syntaxique, la saisie semi-automatique, etc.
• Il y a toujours la possibilité d'une mauvaise configuration qui donne aux gens l'accès à un format texte / bloc / peu importe avec l'exécution php activée. Si php.module (dans D7, D6 n'est pas si strict, par exemple pour les règles d'accès par bloc) n'est même pas activé, ce risque est déjà beaucoup plus faible.
• Si votre CMS autorise l’exécution de PHP, un attaquant qui découvre une faille de sécurité dans XSS ou une élévation de privilèges peut désormais utiliser votre serveur pour des tâches extrêmement malveillantes serveur, piratage d’autres serveurs du réseau pouvant se trouver derrière des pare-feu). En plus de rendre plus douloureuses les petites vulnérabilités, le site devient alors une cible d'attaque plus probable si l'on sait qu'il peut être utilisé pour exécuter php.

Il pourrait y avoir plus de raisons, mais ça devrait suffire :)

Ce code est difficile à déboguer et à maintenir. Je ne connais aucun moyen d'utiliser le contrôle de version pour ce type de code php.

Et c'est vraiment un risque de sécurité potentiel pour les personnes novices dans Drupal ou PHP,

En considérant le cas du filtre PHP utilisé dans un nœud, la raison pour ne pas l'utiliser est que vous limitez le nombre d'utilisateurs pouvant éditer ce nœud, si vous ne souhaitez pas autoriser tous les utilisateurs à utiliser le filtre PHP.
Plutôt que d'utiliser le filtre PHP, il est préférable d'utiliser un module personnalisé qui remplace du texte spécifique dans le contenu du nœud par le résultat du code qu'il exécute (sans utiliser eval()), ou qui ajoute son propre texte au contenu du corps des nœuds. Dans ce cas, n'importe quel utilisateur peut éditer le nœud sans avoir l'autorisation d'ajouter du code PHP arbitraire qui est ensuite exécuté par le filtre PHP.

En règle générale, il est préférable d'éviter, eval()car cela réduit la lisibilité du code, la possibilité pour vous de prédire le chemin d'accès du code (et les éventuelles implications en termes de sécurité) avant l'exécution, et donc la possibilité de déboguer le code.

En dehors d'un site de développement ou de test, je n'activerais pas le filtre PHP ni n'utiliserais du code PHP transmis eval().

Le filtre PHP a été supprimé de Drupal 8. Il s'agit désormais d' un module tiers , non couvert par la stratégie de sécurité . C'est probablement une raison de plus pour ne pas l'utiliser dans les serveurs de production (si les raisons déjà données ne vous ont pas convaincu).

Pour résoudre les divers problèmes spécifiés ci-dessus - difficulté de maintenance du code, de contrôle de version, de recherche d'erreur, vous avez cette possibilité légèrement "klugey":

Créez des fonctions (nommez-les soigneusement, en fonction de ce qu'elles font) dans un fichier toujours inclus - si vous avez un module personnalisé que vous écrivez pour le site, c'est un excellent endroit pour mettre ces fonctions. Le php que vous entrez alors est simplement: return my_specialfunc($somevar);- $somevarici potentiellement l'objet nœud sur lequel vous avez travaillé, ou quelles que soient les autres variables pertinentes ici.

Je trouve que je veux toujours toujours la flexibilité, à certains endroits, d'appeler mon propre code. En utilisant cette technique, la maintenance du code est simple puisqu'il s'agit simplement de modifier la fonction dans le fichier. La détection des erreurs est facile car la fonction apparaîtra dans une trace.

Notez cependant que cela ne résout pas les problèmes de sécurité potentiels. Celles-ci dépendent en grande partie de la sécurité du noyau Drupal. En général, le code contenant une base de données est souvent le talon de sécurité des achillées. Les fonctionnalités utilisant du code contenant une base de données ont tendance à être beaucoup plus exposées à l'exploitation et la sécurité qui les entoure doit être extrêmement étroite. Cependant, Drupal a généralement bien maîtrisé la sécurité de ces problèmes: ils ont été résolus, puis corrigés / résolus rapidement avec de nouvelles versions.

Voici la raison de la vulnérabilité de sécurité pour éviter de donner cette autorisation à vos utilisateurs si vous ne souhaitez pas que vos utilisateurs non-administrateurs modifient directement la base de données.

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Piratage des informations d'identification de la base de données Drupal

Plutôt que de faire quelque chose du genre return functionname($object), il serait préférable d'utiliser le système de jetons / filtres dans la mesure du possible. Il existe des modules tels que Insert View et Embed Node qui peuvent aider dans des situations courantes dans lesquelles des personnes souhaitent intégrer PHP dans des corps de nœuds ou de blocs.

Vous devez vous soucier de la portabilité de vos données. Que se passe-t-il si vous migrez vos nœuds de Drupal 7 vers Drupal 8 et que le corps de certains nœuds en contient <?php whatever_function_that_does_not_exist_anymore(); ?>?

Ne pensez pas à votre projet dans les 5 mois mais dans les 5 ans. Les mises à jour, les bonnes pratiques et la portabilité sont des aspects importants de tout bon projet informatique à mon avis.

Utiliser aussi peu de modules que possible est également un aspect de cela.