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

96

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?

Laxman13
la source
1
Comme d'habitude, cela dépend de la situation! Si vous avez simplement besoin d'un bloc d'impression $ de base au bas de votre page de vues dans un "pied de page de vues", il peut être idéal de le faire via l'interface graphique plutôt que d'écrire tout un fichier tpl dans ce but. Bien entendu, cela dépend aussi du rôle du site et d'autres facteurs: délai serré? Site communautaire d'utilisateurs? Ou simplement un site d'information? Est-ce vital pour les opérations commerciales? etc ... dépend.
Patoshi a été invité le

Réponses:

129

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 :)

Berdir
la source
3
Belle liste :) espérons être une ressource pour les autres
Laxman13
3
@ Laxman13: "aux autres" ... et pour vous aussi! : D @Berdir: +1, de très bons aspects. En passant, vous n’avez pas à écrire tout le code dans un champ de texte, vous pouvez également y inclure un fichier. Par exemple, vous pouvez mettre une seule ligne dans le champ de texte require_once $_SERVER['DOCUMENT_ROOT'].'/sites/all/themes/myTheme/php/stuff.php';et écrire le reste du code dans votre éditeur de texte / IDE. Parfois ce n'est pas un travail facile ou cela prendrait beaucoup de temps de créer son propre module, même en tant que bon développeur PHP. Un petit exemple: Actions conditionnelles Ubercart. Mais il est vrai que garder notre code en base de données n’est pas une bonne chose.
Sk8erPeter
Je veux dire, par exemple, le module UC Conditional Actions a une très grande interface graphique qui permet de gagner beaucoup de temps sans avoir à écrire nos propres codes longs. Vous pouvez créer une action très complexe en quelques minutes avec une méthode "next-next-finish" sur une interface graphique. Mais peut-être voudriez-vous étendre la fonctionnalité avec certains de vos propres codes - dans de nombreux cas, cela ne vaut tout simplement pas la peine de développer un module à cette fin.
Sk8erPeter
1
+1000 - J'ai vu tellement de projets brûlés à peu près par tous les points de cette liste. À une seule occasion de ma vie, l'utilisation du module PHP était le seul moyen de faire quelque chose de sain, et c'était uniquement à cause d'un problème lié à D6 qui avait été corrigé dans D7.
geerlingguy
Merci pour vos détails répondre à cette question. J'ai trouvé une situation en travaillant dans Drupal, que lorsque nous devons ajouter un lien dans 'éditeur de texte', nous devons utiliser du code php dans 'filtre de texte', sinon cela ne fonctionnera pas comme prévu.
Jayendra Kainthola
17

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,

ya.teck
la source
1
Eh bien, si la configuration de bloc exportée vers le code avec des modules de fonctionnalités, poser des extraits php sous contrôle de version ne pose pas de problème.
ya.teck
14

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).

kiamlaluno
la source
11

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.

James
la source
7

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.

Evan Donovan
la source
0

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.

Stef Van Looveren
la source