Mage :: log () не работает при новом обновлении Magento (1.9.4.1)

23

После этого нового обновления (1.9.4.1) Mage :: log () не работает. По-видимому, он имеет отношение к Zend_Validate_File_Extensionстроке 819 в Mage.php, где он проверяет, существует ли файл еще is_readable()до того, как он существует. Я вернул весь log()метод к его предыдущей версии, и он снова работает.

По какому основному каналу я могу связаться с командой Magento, чтобы сообщить об этой проблеме?

rodrigoriome
источник
1
@PiotrSiejczuk Это не работает для новых файлов журнала. Ваш второй комментарий подразумевает, что возможность изменять конфигурацию ротации журналов делает это несерьезной проблемой, и я полностью не согласен. Ваш первый комментарий подразумевает, что это, вероятно, проблема только для OP, или в каком-то крайнем случае, и я тоже очень с этим не согласен. Я полностью понимаю, почему Magento не заметил бы эту ошибку, но эти последствия противоположны тому, что здесь необходимо (независимо от того, являются ли они преднамеренными или нет).
toon81
3
Есть много ситуаций, когда это проблематично: чистая установка (в этом случае system.log еще не существует), создание / установка локальных и сторонних модулей, которые ведут журнал в пользовательских файлах журнала, логируют конфигурации, которые явно не создают / сохранить оригинальный файл журнала.
Аад Матейссен
3
Да, регистрация важна для каждого программного обеспечения, интересно, почему они это пропустили. Я мечтаю, чтобы, когда наступит 2020 год, и команда Magento прекратит поддержку 1.x, они загрузят свою последнюю версию в официальное репозиторий Git, чтобы сообщество могло поддерживать ее в актуальном состоянии
rodrigoriome
1
@cslogic «Я мечтаю, чтобы, когда наступит 2020 год, и команда Magento прекратит поддержку 1.x, они загрузят свою последнюю версию в официальное репозиторий Git, чтобы сообщество могло поддерживать ее в актуальном состоянии» => Уже сделано с OpenMage LTS: github. ru / OpenMage / magento-lts
Frédéric MARTINEZ
1
@ FrédéricMARTINEZ это забавно, Бен Маркс на самом деле рассказал мне об этом репо за 30 минут до того, как я прочел твой комментарий. В любом случае, спасибо, посмотрю на него
rodrigoriome

Ответы:

7

Официальный патч входящий :) Еще жду официального патча ... :(

комментарий piotrekkaminski 13 часов назад

Это текущий официальный патч, который будет перенесен на более ранние версии (это должно работать на последних версиях) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

Источник: https://github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871

sv3n
источник
7

Я суммирую все, что я нашел до сих пор, основываясь на исследованиях и взаимодействии с 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, я верну отредактированный патч и приму оригинальную версию и после этого исправления. Это хорошо подходит для нашего процесса сборки и внутренней политики, может отличаться для вас. Независимо от того, что вы выбрали, лучше применить этот патч раньше, чем позже.

Димитар Иванов
источник
1
По состоянию на 25 июня Magento выпустила SUPEE-11155, Magento Commerce 1.14.4.2 и Magento Open Source 1.9.4.2, которые включают исправление для этой проблемы. По сути, патч Петра Каминского был включен.
Аад Матейссен
4

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

Петр Сейчук
источник
Это действительно плохая практика, но я не могу выжить без регистрации. Надеюсь, Adobe скоро это исправит
Родригориом
да, мне пришлось воссоздать все файлы журналов, потому что сценарий logrotator удалял файлы и создавал их архивы. Мне нужно будет найти лучший сценарий magento не исправить это.
Кальвин Клиен
1
@KalvinKlien: Вы пытались использовать опцию: copytruncate для logrotate? «Обрезать исходный файл журнала до нулевого размера на месте после создания копии, вместо перемещения старого файла журнала и, при необходимости, создания нового. Его можно использовать, когда какой-либо программе нельзя сказать, чтобы она закрыла свой файл журнала и, следовательно, могла продолжить запись ( добавление) к предыдущему файлу журнала навсегда. Обратите внимание, что между копированием файла и его усечением существует очень маленький временной интервал, поэтому некоторые данные журналирования могут быть потеряны. При использовании этой опции опция создания не будет действовать, так как старый файл журнала остается на месте ".
Петр Сейчук
Спасибо @PiotrSiejczuk! Я использовал это: / путь / var / log / * log {вращать 7 копий, ежедневно сжимать отсутствующий notifempty}
Kalvin Klien
1

Мое временное решение было копировать 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, я проверяю это снова.

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

Рикардо Мартинс
источник
1

Я предлагаю не изменять основной код и использовать такое обновление ( 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';
");
Мехди Чауш
источник
0

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

Антуан ЭТИВАНТ
источник
Для этой проблемы подпапки я понятия не имею, но для фактической проблемы регистрации мы поддерживаем этот кусок кода gist.github.com/piotrekkaminski/…
rodrigoriome