Mage :: log () não funciona na nova atualização Magento (1.9.4.1)

23

Após esta nova atualização (1.9.4.1), o Mage :: log () não está funcionando. Aparentemente, tem algo a ver com Zend_Validate_File_Extensiona linha 819 no Mage.php, onde verifica se o arquivo is_readable()antes mesmo de existir. Invertai todo o log()método para sua versão anterior e ele está funcionando novamente.

Qual é o principal canal em que posso entrar em contato com a equipe Magento para relatar esse problema?

magento-1.9 log bug magento-1.9.4.1 rodrigoriome
fonte
1
@PiotrSiejczuk Isso não funciona para novos arquivos de log. Seu segundo comentário implica que a capacidade de alterar a configuração de rotação de logs não torna esse um problema sério e eu discordo completamente. Seu primeiro comentário implica que isso provavelmente é apenas um problema para OP, ou em algum tipo de caso extremo, e eu também discordo muito disso. Eu entendo completamente por que o Magento não teria notado esse bug, mas essas implicações são o oposto do que é necessário aqui (sejam deliberadas ou não).
toon81
3
Há muitas situações em que isso é problemático: instalações limpas (nesse caso, o system.log ainda não existe), criação / instalação de módulos locais e de terceiros que fazem logon em arquivos de log personalizados, registram configurações de logotipos que não criam / mantenha o arquivo de log original.
Aad Mathijssen
3
Sim, o registro é essencial para todos os softwares, eu me pergunto por que eles deixaram isso passar. Meu sonho é que, quando 2020 chegar e a equipe Magento pare de suportar o 1.x, eles enviem sua última versão para um repositório oficial do Git, para que a comunidade possa mantê-la atualizada
rodrigoriome
1
@cslogic "Meu sonho é que quando 2020 chegar e a equipe Magento pare de oferecer suporte ao 1.x, eles enviem sua última versão para um repositório oficial do Git, para que a comunidade possa mantê-la atualizada" => Já foi feito com o OpenMage LTS: github. com / OpenMage / magento-lts
Frédéric MARTINEZ
1
@ FrédéricMARTINEZ isso é engraçado, Ben Marks me contou sobre o repo cerca de 30 minutos antes de ler o seu comentário .. Obrigado de qualquer maneira, dê uma olhada
rodrigoriome

Respostas:

7

Resumirei tudo o que encontrei até agora com base em pesquisa e interação com o Magento, tanto com suporte quanto com o Slack, no que diz respeito à aplicação de patches no SUPEE-11086. O que pode ser feito:

ATUALIZAÇÃO 2: O problema foi resolvido no próximo PATCH SUPEE-11155 - https://magento.com/security/patches/supee-11155 . Como sempre, antes de aplicar o patch, verifique os possíveis problemas do thread - Patch de segurança SUPEE-11155 - Possíveis problemas? Agradecemos a Aad Mathijssen pelo ótimo comentário.

Atualização: Um patch oficial está disponível sob demanda para a versão EE. Basicamente, é a essência de Piotr Kaminski envolvida como arquivo de patch do Magento.

  1. Exclua as alterações app/Mage.phpno arquivo de patch. Foi o que fiz até agora.
    Prós - o registro funciona como antes.
    Contras - editando um arquivo de correção, o log não é protegido de uma possível exploração (mas isso deve ser um risco muito baixo). Quando o Magento lançar uma correção oficial, você precisará revertê-la e aplicar o Patch não editado original.
  2. Adicione outro patch no topo com base na essência de Piotr Kaminski - https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f . Piotr Kaminski faz parte do Magento encarregado da segurança, então isso vem direto da boca do cavalo. A essência foi compartilhada no Magento e provavelmente terminará como SUPEE-11086 v1.1.
    Prós - Esta é a maneira Magento
    Contras - Você terá que esperar que isso se torne oficial ou assumir a responsabilidade e empacotá-lo como um patch, o que fará com que você volte a ter que reverter uma vez que um patch oficial for lançado.
    Uma pequena variação seria, em vez de adicionar dois patches para editar o original com essas alterações.
  3. Edite Zend_Validate_File_Extension::isValide remova a validação de existência de arquivo. há uma longa discussão no Magento LTS github - https://github.com/OpenMage/magento-lts/pull/648 . O isValidmétodo faz coisas que não se espera que sejam feitas, então alguns membros propõem consertá-lo. Minha opinião é que essa não é uma boa solução, sim, o código é ruim, mas estava lá para sempre e pode ser usado em módulos / códigos personalizados. Pelo contrário, o pior que pode acontecer é que os arquivos não sejam verificados quanto à existência.
    Prós - uma correção bastante simples
    Contras - altera um arquivo de biblioteca e altera sua funcionalidade.
    Você pode aplicar isso como um patch personalizado ou reescrever toda a classe no localpool de códigos.

Eu escolhi editar o patch e, quando a v1.1 chegar, reverterá o patch editado e aplicarei a versão original e depois dessa correção. Isso combina bem com nosso processo de compilação e política interna; pode ser diferente para você. Não importa o que você escolher, é melhor aplicar esse patch mais cedo ou mais tarde.

Dimitar Ivanov
fonte
1
A partir de 25 de junho, o Magento lançou o SUPEE-11155, o Magento Commerce 1.14.4.2 e o Magento Open Source 1.9.4.2 que incluem uma correção para esse problema. Essencialmente, o patch de Piotr Kaminski foi incluído.
Aad Mathijssen
4

Algo das contribuições da comunidade. Há um novo Validador usado Zend_Validate_File_Extension conforme abaixo:

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

"A solução é editar o patch e apenas remover as alterações do app / Mage.php. Eu desencorajaria fortemente essa prática, mas a situação é crítica".

Piotr Siejczuk
fonte
É de fato uma prática ruim, mas não posso sobreviver sem registrar. Espero que a Adobe possa corrigi-lo em breve
rodrigoriome
Sim, eu tive que recriar todos os arquivos de log porque o script logrotator estava excluindo arquivos e criando zips deles. Vou precisar encontrar um script melhor do magento não conserta thi.
Kalvin Klien 03/04
1
@KalvinKlien: Você tentou com: copytruncate opção de logrotate? "Trunque o arquivo de log original para o tamanho zero após criar uma cópia, em vez de mover o arquivo de log antigo e, opcionalmente, criar um novo. Ele pode ser usado quando algum programa não pode ser instruído a fechar seu arquivo de log e, portanto, pode continuar gravando ( anexar) ao arquivo de log anterior para sempre.Tenha em mente que há uma pequena fatia de tempo entre copiar e truncá-lo, para que alguns dados de registro possam ser perdidos.Quando essa opção é usada, a opção de criação não tem efeito, pois o arquivo de log antigo permanece no local ".
Piotr Siejczuk 04/04
Obrigado @PiotrSiejczuk! Eu usei isso: / path / var / log / * log {rotate 7 copytruncate diariamente comprimir missingok notifempty}
Kalvin Klien
1

Minha solução temporária era para copiar lib/Zend/Validate/File/Extension.phppara app/code/local/Zend/Validate/File/Extension.phpe remover esta parte do código do isValid()método:

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

Seria ...

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

Quando o Magento 1.9.4.2 é lançado, verifico isso novamente.

De fato, o arquivo não está legível ou não existe, não significa que o nome do arquivo não seja válido, certo?

Ricardo Martins
fonte
1

Sugiro não alterar o código principal e usar uma atualização como esta ( 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';
");
Mehdi Chaouch
fonte
0

Há outro problema (que pode ser deliberado pela equipe do Magento) que impede a capacidade de gravar arquivos de log dentro de subpastas. Por exemplo:

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

Nas versões anteriores, essa chamada teria criado um arquivo no local:

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

Mas como há uma basename()chamada de função no Mage::log()método, o arquivo é gravado em:

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

Aqui está o código incriminado em app/Mage.php:

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

Mesmo que não esteja especialmente relacionado ao 1.9.4.1, o problema começou a ocorrer recentemente (em torno das versões mais recentes do 1.9.3.x) e é muito irritante quando você precisa lidar com muitos arquivos de log, às vezes com o mesmo nome ( mas inicialmente em subpastas diferentes).

Como esse pedaço de código provavelmente é deliberado pela equipe do Magento, acho que não há nenhum plano para corrigi-lo em uma versão posterior, o que implica hackear para restaurar o comportamento inicial ...

Antoine ETIEVANT
fonte
Para esse problema de subpasta, não tenho idéia, mas, para o problema real de registro, estamos defendendo esse pedaço de código gist.github.com/piotrekkaminski/…
rodrigoriome