Почему так много функций PHP запрещено в стандарте кодирования ЭКГ Magento?

30

Стандарт кодирования ЭКГ Magento кажется (по крайней мере, официальным) стандартом для расширений Magento 1:

https://github.com/magento-ecg/coding-standard

Но я не понимаю причин, лежащих в основе всех правил, и правила перехватчика кода с их одними сообщениями мало помогают. Есть ли подробная документация о стандарте? Я знаю , что общие лучшие практик и разработчики руководства , но не могу найти что - то конкретное об этих стандартах кодирования.

Больше всего меня беспокоит строгость в том, что я не использую функции PHP.

Например: почему запрещена каждая PHP-функция, связанная с файловой системой ?

Я предполагаю, что вы должны использовать Varien_Io_Fileи Varien_File_Objectт.д., но даже разработчики ядра не знают обо всех классах Varien, и вы часто находите такие вещи, как Mage_ImportExport_Model_Import_Adapter_Csv:

    $this->_fileHandler = fopen($this->_source, 'r');

Итак, ядро ​​не лучший пример, как часто.

Другие ИМХО сомнительные запрещенные функции:

  • mb_parse_str
  • parse_str
  • parse_url

  • base64_decode

    • да, он используется в бэкдорах, но запрета evalдолжно быть достаточно, и существуют законные варианты использования, такие как кодирование двоичных данных. И кроме json_decode(что не запрещено), для этого нет основного помощника.

Источник: https://github.com/magento-ecg/coding-standard/blob/master/Sniffs/Security/ForbiddenFunctionSniff.php

По сути, мой вопрос сводится к следующему: где задокументирован этот стандарт? И / или есть ли список «вещей, которые нужно использовать вместо этих собственных функций PHP»?

code-analysis magento-ecg coding-standards documentation Фабиан Шменглер
источник
1
Magento построен на Zend Framework. Почему вы не используете стандарты Zend?
Жартауник
ЭКГ выполняет больше проверок, характерных для Magento, например, если есть модели, загруженные в циклы. Это не касается базовых проверок стиля, таких как отступы и скобки.
Фабиан Шменглер
1
Перечисление «необработанных SQL-запросов» как запрещенных также кажется наивным. Конечно, вы не делаете необработанный SQL в большинстве ситуаций, но бывают ситуации, когда он не только уместен, но и необходим (например, сложный импорт / экспорт)
pspahn
1
@pspahn Я понимаю вашу точку зрения, но разве Zend_Dbконструктор запросов не должен генерировать какие-либо SQL-запросы?
Фабиан Шменглер
Конечно, но вы не можете также создать selectоператор, Zend_Dbиспользуя в качестве входных данных сырой SQL? Я предположил, что именно это делает github.com/kalenjordan/custom-reports в бэкэнде.
pspahn

Ответы:

28

Получил неофициальный ответ от команды ЭКГ на это:

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

Во-вторых, предполагалось, что лучше использовать оболочки (функции / классы) Magento, если они существуют, поскольку они могут предложить дополнительную функциональность или защиту.

В-третьих, что касается конкретных вызовов, base64_decode часто используется для вредоносного внедренного кода, а остальные, такие как parse_str, могут быть уязвимы, особенно при обработке неизвестного или предоставленного пользователем ввода - см., Например, http://php-security.org/2010/05/ 31 / швабры-2010-049-PHP-parse_str-прерывание-памяти коррупции уязвимость /

Опять же, это помечает его для проверки, а не отклоняет код как плохой.

Надеюсь, это поможет.

Петр Каминский
источник
Тогда почему они пишут «функция запрещена» вместо «вы должны просмотреть код, чтобы убедиться в его законном использовании» ?!
черный
11

Стандарт кодирования имеет две цели.

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

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

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

немного дополнительной информации

Файловые функции часто допускают использование упаковщиков protocoll, то есть путь к файлу, начинающийся с http: //, приводит к запросу http, который часто используется для «звонка домой», и время от времени убивает магазин, поскольку сервер недоступен (Тайм-аут по умолчанию 30 секунд) и встроенный в очень центральное место.

Каждый, кто понял, никто не верит, сколько отверстий для инъекций все еще существует. Отличный пример был, как это было в Поиске на сайте Mysql.

где-то есть основной помощник для json_decode, но у него очень старая реализация, просто используйте json_decode. Не знаю, почему это должно быть запрещено.

gettext - интересная PHP-часть, я помню, что она использует некоторую нативную реализацию ОС, которая может иметь проблемы, если вы используете ее параллельно с разными языками (как это обычно бывает, когда в вашем магазине более одного языка. , но также не должно быть необходимости в Magento Context.

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

Flyingmana
источник