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: проблема решена в следующем патче SUPEE-11155 - https://magento.com/security/patches/supee-11155 . Как всегда перед применением исправления проверьте ветку возможных проблем - Патч безопасности SUPEE-11155 - Возможные проблемы? Спасибо Aad Mathijssen за отличный комментарий.

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

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

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

Что-то из входов сообщества. Существует новый Validator используется 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, я думаю, что нет никакого плана, чтобы исправить это в следующем выпуске, который подразумевает взломать его, чтобы восстановить первоначальное поведение ...