Mage :: log () не працює над новим оновленням Magento (1.9.4.1)

Після цього нового оновлення (1.9.4.1) Mage :: log () не працює. Мабуть, це має щось Zend_Validate_File_Extensionспільне з рядком 819 в Mage.php, де він перевіряє, чи is_readable()існує файл, перш ніж він взагалі існує. Я повернув весь log()метод до його попередньої версії, і він працює знову.

Який головний канал, з яким я можу зв’язатися з командою Magento, щоб повідомити про це?

Офіційний патч вхідний :) Ще чекаю офіційного патчу ... :(

piotrekkaminski прокоментував 13 годин тому

Це поточний офіційний патч, який буде переноситися на більш ранні версії (це повинно працювати останнім часом) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

^{Джерело: https://github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871}

Я підсумую все, що я знайшов поки що, ґрунтуючись на дослідженнях та взаємодії з Magento, як підтримка, так і Slack щодо виправлення з SUPEE-11086. Що можна зробити:

ОНОВЛЕННЯ 2: Проблема вирішується в наступному PATCH SUPEE-11155 - https://magento.com/security/patches/supee-11155 . Як завжди, перш ніж застосовувати патч перевірити наявність можливих проблем з потоком - Patch Security SUPEE-11155 - Можливі проблеми? Дякуємо Ааду Матхійсену за чудовий коментар.

Оновлення: Офіційний патч доступний на вимогу для версії EE. По суті, це суть Пьотра Камінського, обгорнута як патч-файл Magento.

1. Видаліть зміни app/Mage.phpу файлі патча. Це те, що я робив досі.
   Плюси - лісозаготівля працює як і раніше.
   Мінуси - редагування файлу патчу, ведення журналу не захищене від можливого використання (але це має бути дуже низьким ризиком). Коли Magento випустить офіційний виправлення, вам доведеться відновити його та застосувати оригінальний нередагований патч.
2. Додайте ще один патч зверху на основі суті Петра Камінського - https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f . Пьотр Камінський є частиною Магенто, який відповідає за безпеку, тому це відбувається прямо з уст коня. Gist було поділено в Magento слабістю і, ймовірно, закінчиться як SUPEE-11086 v1.1.
   Плюси - це
   мінуси Magento - вам доведеться почекати, коли це стане офіційним, або взяти на себе відповідальність і упакувати його як патч, який поверне вас до необхідності повернути, коли офіційний патч буде встановлений.
   Невелика варіація буде замість того, щоб додати два патчі для редагування оригіналу з цими змінами.
3. Відредагуйте Zend_Validate_File_Extension::isValidта видаліть перевірку існування файлів. триває дискусія в Magento LTS github - https://github.com/OpenMage/magento-lts/pull/648 . isValidМетод робить речі це не повинні робити, так що деякі члени пропонують , щоб виправити це. На мою думку, це не гарне рішення, так, код - це погано, але він був там назавжди і може використовуватися у спеціальних модулях / кодах. Навпаки, найгірше, що може статися, - це те, що файли не перевіряються на наявність.
   Плюси - досить просте виправлення
   мінусів - змінює файл бібліотеки та вносить зміни в його функціональність.
   Ви можете застосувати це або як власний патч, або переписавши весь клас у localпул кодів.

Я вирішив редагувати патч, і коли з'явиться v1.1, я відновлю відредагований патч і застосую оригінальну версію і після цього виправлюю. Це добре відповідає нашому процесу збирання та внутрішній політиці, для вас це може бути інакше. Незалежно від того, що ви вибрали, краще застосувати цей пластир раніше, ніж пізніше.

Щось із вкладів громад Є новий валідатор, використовується Zend_Validate_File_Extension, як зазначено нижче:

https://github.com/brentwpeterson/magento-patches/blob/master/CE1.9/PATCH_SUPEE-11086_CE_1.9.4.0_v1-2019-03-26-03-05-04.sh#L183

"Рішення полягає в редагуванні виправлення та просто видаленні змін із app / Mage.php, я б сильно відмовив від цієї практики, але ситуація є критичною".

Моє тимчасове рішення було копіювати lib/Zend/Validate/File/Extension.phpв app/code/local/Zend/Validate/File/Extension.phpі видалити цю частину коду з isValid()методу:

    // Is file readable ?
    #require_once 'Zend/Loader.php';
    if (!Zend_Loader::isReadable($value)) {
        return $this->_throw($file, self::NOT_FOUND);
    }

Це стане ...

public function isValid($value, $file = null)
{
    if ($file !== null) {
        $info['extension'] = substr($file['name'], strrpos($file['name'], '.') + 1);
    } else {
        $info = pathinfo($value);
...

Коли Magento 1.9.4.2 виходить, я перевіряю це ще раз.

Насправді те, що файл не читається або не існує, не означає, що ім'я файлу недійсне, правда?

Я пропоную не змінювати основний код і використовувати таке оновлення ( https://gist.github.com/mehdichaouch/99c67298b5a65f81219c9b69942b6fe7 )

$installer->run("
    INSERT INTO `{$installer->getTable('core_config_data')}` (scope, scope_id, path, value)
    VALUES ('default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv')
    ON DUPLICATE KEY UPDATE value = 'log,txt,html,csv';
");

Існує ще одна проблема (яка може бути навмисно командою Magento), яка перешкоджає можливості запису файлів журналів всередині папок. Наприклад:

Mage::log('Some log information', Zend_Log::DEBUG, 'somefolder/anotherfolder/somelogfile.log', true);

У попередніх версіях цей виклик створив би файл у розташуванні:

/your-magento-app-root-folder/var/log/somefolder/anotherfolder/somelogfile.log

Але оскільки basename()у Mage::log()методі є виклик функції , файл записується за адресою:

/your-magento-app-root-folder/var/log/somelogfile.log.

Ось інкримінований код у app/Mage.php:

$file = empty($file) ?
    (string) self::getConfig()->getNode('dev/log/file', Mage_Core_Model_Store::DEFAULT_CODE) : basename($file);

Навіть якщо це не особливо пов'язане з 1.9.4.1, проблема почала траплятися нещодавно (близько останніх версій 1.9.3.x) і дуже дратує, коли вам доведеться мати багато файлів журналів, іноді з тим самим іменем ( але спочатку в різних папках).

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