Каковы недостатки использования кода PHP Filter в блоках, узлах, представлениях-аргументах и ​​т. Д.?

Я много раз видел, как люди говорили, что не следует использовать собственный фильтр PHP / PHP (из пользовательского интерфейса Drupal) в блоках, узлах, аргументах представления, правилах и т. Д. Я немного искал и не нашел много, похоже это лучшая практика Drupal, которую все "просто знают".

Я понимаю, что это представляет потенциальную угрозу безопасности, особенно в руках конечных пользователей или людей, плохо знакомых с Drupal или PHP, но как разработчик / строитель сайтов, каковы реальные причины не использовать пользовательский PHP из пользовательского интерфейса Drupal?

Несколько причин:

• Код в вашей базе данных не может контролироваться версией, и его также будет сложнее найти в дальнейшем.
• Код Eval () намного медленнее, чем что-то жестко закодированное в файле.
• Если где-то в этом коде есть ошибка, вы получите очень бесполезное сообщение об ошибке (ошибка в коде eval () в строке 3), и вам, возможно, даже пришлось пройтись по базе данных вручную, чтобы найти и исправить ошибку. Если он находится внутри блока, который отображается на всех страницах и приводит к фатальной ошибке, например, все время.
• Вышесказанное также верно при обновлении с Drupal 6 до 7 и любых API, которые вы использовали, были изменены. Так что вам придется переносить код во время миграции. Если код находится в модуле, вы можете заранее перенести его, протестировать и развернуть только на новом сайте. Внутри узла или блока он будет работать только с Drupal 6 или 7.
• Написание и сопровождение этого кода также сложнее, потому что вы работаете в текстовом поле внутри вашего браузера. Наличие этого в модуле позволяет вам использовать редактор / IDE с подсветкой синтаксиса, автозаполнением и так далее.
• Всегда есть возможность неверной конфигурации, которая дает людям доступ к текстовому формату / блоку / любому другому с включенным выполнением php. Если php.module (в D7, D6 не такой строгий, например, для правил доступа к блокам) даже не включен, этот риск уже намного ниже.
• Если ваша CMS позволяет выполнять PHP, то злоумышленник, обнаруживший уязвимость безопасности XSS или повышение привилегий, теперь может использовать ваш сервер для чрезвычайно злонамеренных действий (в качестве части DDOS, рассылки спама, размещения вредоносных программ, взлома других сайтов / баз данных на сервере). сервер, взломав другие серверы в сети, которые могут находиться за брандмауэрами). В дополнение к тому, что небольшие уязвимости становятся более болезненными, это делает сайт более вероятной целью атаки, если известно, что он может быть использован для выполнения php.

Может быть больше причин, но этого должно быть достаточно :)

Этот код трудно отлаживать и поддерживать. Я не знаю, как использовать контроль версий для такого рода PHP-кода.

И это действительно потенциальная угроза безопасности для людей, плохо знакомых с Drupal или PHP,

Рассматривая случай использования фильтра PHP в узле, причина не использовать его состоит в том, что вы ограничиваете пользователей, которые могут редактировать этот узел, если вы не хотите разрешить всем пользователям использовать фильтр PHP.
Вместо использования фильтра PHP лучше использовать пользовательский модуль, который заменяет определенный текст в содержимом узла на результат кода, который он выполняет (без использования eval()), или который добавляет свой собственный текст к содержимому тела узлов. В этом случае любой пользователь может редактировать узел, не имея разрешения на добавление произвольного кода PHP, который затем запускается фильтром PHP.

Как правило, этого лучше избегать, eval()потому что это снижает читабельность кода, возможность прогнозировать путь к коду (и возможные последствия для безопасности) до времени выполнения и, следовательно, возможность отладки кода.

Помимо разработки или тестового сайта, я бы не включил фильтр PHP и не использовал PHP-код, который был передан eval().

Фильтр PHP был удален из Drupal 8. Теперь он является сторонним модулем , на который не распространяется политика безопасности . Вероятно, это еще одна причина, по которой он не используется на производственных серверах (если уже приведенные причины не убедили вас).

В качестве обходного пути для различных проблем, указанных выше - сложности сопровождения кода, контроля версий, поиска ошибок, у вас есть немного «клугейная» возможность:

Создайте функции (назовите их внимательно, в соответствии с тем, что они делают) в некотором файле, который всегда включен - если у вас есть собственный модуль, который вы пишете для сайта, это отличное место для размещения этих функций. В таком случае php, который вы вводите, просто: return my_specialfunc($somevar);- $somevarздесь, возможно, объект узла, над которым работали, или любые другие переменные, которые здесь важны

Я нахожу, что я все еще обычно хочу гибкость, в некоторых местах, для вызова моего собственного кода. Используя эту технику, поддерживать код легко, так как это просто вопрос изменения функции в файле. Обнаружение ошибок легко, так как функция будет отображаться в обратном направлении.

Однако обратите внимание, что это не решает потенциальные проблемы безопасности. Это во многом зависит от безопасности ядра Drupal. Вообще, код, содержащий базу данных, часто является пятой безопасности ахиллеев - функциональные возможности, использующие код, содержащийся в базе данных, имеют тенденцию быть гораздо более подверженными эксплуатации, и безопасность вокруг них должна быть очень жесткой. Тем не менее, Drupal в целом неплохо поддерживал безопасность для этих проблем - они возникли, а затем быстро исправлены / решены с помощью новых выпусков.

Вот причина уязвимости в безопасности, чтобы не давать это разрешение своим пользователям, если вы не хотите, чтобы пользователи без прав администратора изменяли базу данных напрямую.

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

Взлом учетных данных Drupal db

Вместо того, чтобы делать что-то подобное return functionname($object), было бы лучше использовать систему токенов / фильтров, насколько это возможно. Существуют такие модули, как Insert View и Embed Node, которые могут помочь в обычных обстоятельствах, когда люди захотят встроить PHP в тела узлов или блоков.

Вы должны заботиться о переносимости ваших данных. Что если вы перенесете свои узлы с drupal 7 на drupal 8 и <?php whatever_function_that_does_not_exist_anymore(); ?>в нем есть текст основного текста какого-либо узла ?

Не думайте о своем проекте в течение 5 месяцев, но в течение 5 лет. На мой взгляд, обновления, передовой опыт и мобильность являются важными аспектами любого хорошего ИТ-проекта.

Использование как можно меньшего количества модулей также является одним из аспектов этого.