Mage :: log () ne fonctionne pas sur la nouvelle mise à jour de Magento (1.9.4.1)

Après cette nouvelle mise à jour (1.9.4.1), Mage :: log () ne fonctionne pas. Apparemment, cela a quelque chose à voir avec la Zend_Validate_File_Extensionligne 819 de Mage.php où il vérifie si le fichier is_readable()avant même qu'il existe. J'ai inversé toute la log()méthode à sa version précédente et cela fonctionne à nouveau.

Quel est le canal principal avec lequel je peux contacter l'équipe Magento pour signaler ce problème?

Patch officiel entrant :) Toujours en attente du patch officiel ... :(

piotrekkaminski a commenté il y a 13 heures

Il s'agit du correctif officiel actuel qui sera porté sur les versions antérieures (cela devrait fonctionner sur la dernière version) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

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

Je vais résumer tout ce que j'ai trouvé jusqu'à présent, basé sur la recherche et l'interaction avec Magento et Slack en ce qui concerne les correctifs avec SUPEE-11086. Ce qui peut être fait:

MISE À JOUR 2: Le problème est résolu dans le prochain PATCH SUPEE-11155 - https://magento.com/security/patches/supee-11155 . Comme toujours avant d'appliquer la vérification des correctifs pour le fil des problèmes possibles - Patch de sécurité SUPEE-11155 - Problèmes possibles? Merci à Aad Mathijssen pour son excellent commentaire.

Mise à jour: Un patch officiel est disponible sur demande pour la version EE. Fondamentalement, c'est l'essentiel de Piotr Kaminski enveloppé sous forme de fichier patch Magento.

1. Supprimez les modifications pour app/Mage.phpdans le fichier de patch. C'est ce que j'ai fait jusqu'à présent.
   Avantages - la journalisation fonctionne comme auparavant.
   Inconvénients - en éditant un fichier patch, la journalisation n'est pas protégée contre un éventuel exploit (mais cela devrait présenter un risque très faible). Lorsque Magento publiera un correctif officiel, vous devrez le rétablir et appliquer le correctif original non modifié.
2. Ajoutez un autre patch sur le dessus basé sur l'essentiel de Piotr Kaminski - https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f . Piotr Kaminski fait partie de Magento en charge de la sécurité, cela vient donc directement de la bouche du cheval. Gist a été partagé dans Magento slack et se terminera probablement par SUPEE-11086 v1.1.
   Pour - C'est la manière Magento
   Contre - Vous devrez attendre que cela devienne officiel, ou prendre la responsabilité et le conditionner en tant que patch vous-même, ce qui vous ramènera à devoir revenir une fois qu'un patch officiel est en place.
   Une légère variation serait au lieu d'ajouter deux patchs pour éditer l'original avec ces changements.
3. Modifier Zend_Validate_File_Extension::isValidet supprimer la validation d'existence de fichier. il y a une longue discussion dans Magento LTS github - https://github.com/OpenMage/magento-lts/pull/648 . La isValidméthode fait des choses qu'elle ne devrait pas faire, donc certains membres proposent de la corriger. Mon avis est que ce n'est pas une bonne solution, oui le code est mauvais, mais il était là pour toujours et peut être utilisé dans des modules / codes personnalisés. Au contraire, le pire qui puisse arriver est que les fichiers ne soient pas vérifiés.
   Pour - une solution plutôt simple
   Contre - modifie un fichier de bibliothèque et modifie sa fonctionnalité.
   Vous pouvez l'appliquer sous forme de correctif personnalisé ou en réécrivant toute la classe dans le localpool de codes.

J'ai choisi d'éditer le patch, et quand une v1.1 arrivera, je reviendrai sur le patch édité et appliquerai la version originale et après ce correctif. Cela convient bien à notre processus de construction et à notre politique interne, cela pourrait être différent pour vous. Peu importe ce que vous avez choisi, il vaut mieux appliquer ce patch plus tôt que tard.

Quelque chose des contributions de la communauté. Il y a un nouveau validateur est utilisé Zend_Validate_File_Extension comme ci-dessous:

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

"La solution consiste à modifier le correctif et à supprimer les modifications de app / Mage.php, je déconseille fortement cette pratique, mais la situation est critique".

Ma solution temporaire a été de copier lib/Zend/Validate/File/Extension.phpà app/code/local/Zend/Validate/File/Extension.phpet retirer cette partie du code de la isValid()méthode:

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

Cela deviendrait ...

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

Lorsque Magento 1.9.4.2 est sorti, je vérifie à nouveau.

En fait, le fichier n'est pas lisible ou n'existe pas, cela ne signifie pas que le nom du fichier n'est pas valide, non?

Je suggère de ne pas modifier le code principal et d'utiliser une mise à jour comme celle-ci ( 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';
");

Il existe un autre problème (qui peut être délibéré de la part de l'équipe Magento) qui empêche la possibilité d'écrire des fichiers journaux dans des sous-dossiers. Par exemple:

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

Dans les versions antérieures, cet appel aurait créé un fichier à l'emplacement:

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

Mais puisqu'il y a un basename()appel de fonction dans la Mage::log()méthode, le fichier est écrit à:

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

Voici le code incriminé dans app/Mage.php:

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

Même s'il n'est pas spécialement lié à 1.9.4.1, le problème a commencé à se produire récemment (autour des dernières versions 1.9.3.x) et est très ennuyeux lorsque vous devez gérer un grand nombre de fichiers journaux, parfois avec le même nom ( mais initialement dans différents sous-dossiers).

Comme ce morceau de code est probablement délibéré de la part de l'équipe Magento, je pense qu'il n'est pas prévu de le corriger dans une version ultérieure, ce qui implique de le pirater pour restaurer le comportement initial ...