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

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?

Patch oficial recebido :) Ainda à espera do patch oficial ... :(

piotrekkaminski comentou 13 horas atrás

Este é o patch oficial atual que será portado para versões anteriores (isso deve funcionar nas últimas) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

^{Fonte: https://github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871}

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.

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".

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?

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';
");

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 ...