Чому стільки функцій PHP заборонено в стандарті кодування Magento ECG?

Екологічний стандарт кодування 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"?

— Фабіан Шменглер
джерело

Magento побудований на Zend Framework. Чому ви не використовуєте стандарти Zend?

— zhataunik

ЕКГ робить більше Magento-перевірок, наприклад, якщо є моделі, завантажені в петлі. Мова йде не про базові перевірки стилю, як відступ та дужки.

— Фабіан Шменглер

Перерахування "необроблених запитів SQL" як заборонених також здається наївним. Звичайно, у більшості ситуацій ви не працюєте з сирим SQL, але, безумовно, є випадки, коли це не тільки доречно, але й необхідне (тобто складний імпорт / експорт)

— pspahn

@pspahn Я бачу вашу думку, але чи не повинен Zend_Dbконструктор запитів генерувати будь-які запити SQL?

— Фабіан Шменглер

Звичайно, але хіба ви також не можете створити selectоперацію, Zend_Dbвикористовуючи необроблений SQL як вхід? Я припускав, що саме це робить github.com/kalenjordan/custom-reports у бекенді .

— pspahn

Відповіді:

Отримав неофіційну відповідь від команди ЕКГ на те, що:

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

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

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

Знову ж таки, це позначає його для огляду, не відкидаючи код як поганий.

Сподіваюся, це допомагає.

— Пьотр Камінський
джерело

Тоді чому вони пишуть "функція заборонена", а не "ви повинні переглянути код, щоб забезпечити його законне використання" ?!

— Чорний

Стандарт кодування має дві цілі.

полегшити пошук можливо проблемних деталей. Досвідчений розробник уже знає, які частини нового модуля йому потрібно переглянути, і цей стандарт маркує і перераховує їх для нього. Він не може вилучити ці частини, але переглянути, якщо вони необхідні, проблематичні чи обидва.
підтримка недосвідчених розробників, яких речей йому слід уникати. Хоча всі позначені функції можуть бути хорошим рішенням для конкретних проблем, їх дуже легко використовувати проблематично. Це спонукає розробників думати більше про проблему, а часто до кращого рішення, яке не суперечить стандарту.

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

трохи додаткової інформації

Функції файлів часто дозволяють використовувати обгортки протокол, означає, що шлях до файлу, що починається з http: // призводить до повторного запиту http, який часто використовується для "виклику додому" і час від часу вбиває магазин, оскільки сервер недоступний (30 секунд за замовчуванням) та вбудований у дуже центральне місце.

Все, що було реалізовано в sql, ніхто не вірить, скільки ще є отворів для впорскування sql. Чудовим прикладом було те, що пошук на веб-сайті Mysql мав такий.

десь є основний помічник для json_decode, але він має дуже стару реалізацію, просто використовуйте json_decode. Немає ідеї, чому це слід забороняти.

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

Пройшовши далі список, це, здається, є лише списком з якомога більшою кількістю функцій. Історія насправді смішна, здається, вони вилучили деякі функції зі списку, після того як вони помітили, вони користуються нею. : D

— Flyingmana
джерело