Mage :: log () no funciona en la nueva actualización de Magento (1.9.4.1)

Después de esta nueva actualización (1.9.4.1), Mage :: log () no funciona. Aparentemente, tiene algo que ver con la Zend_Validate_File_Extensionlínea 819 en Mage.php, donde comprueba si el archivo is_readable()incluso existe. Invertí todo el log()método a su versión anterior y está funcionando nuevamente.

¿Cuál es el canal principal con el que puedo contactar al equipo de Magento para informar este problema?

Parche oficial entrante :) Todavía estoy esperando el parche oficial ... :(

piotrekkaminski comentó hace 13 horas

Este es el parche oficial actual que será portado a versiones anteriores (esto debería funcionar en la última) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

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

Resumiré todo lo que encontré hasta ahora basado en la investigación y la interacción con Magento, tanto el soporte como Slack, en lo que respecta a parches con SUPEE-11086. Qué se puede hacer:

ACTUALIZACIÓN 2: El problema se resuelve en el próximo PATCH SUPEE-11155: https://magento.com/security/patches/supee-11155 . Como siempre, antes de aplicar el parche, verifique el hilo de posibles problemas. Gracias a Aad Mathijssen por el gran comentario.

Actualización: un parche oficial está disponible bajo demanda para la versión EE. Básicamente, es la esencia de Piotr Kaminski envuelta como un archivo de parche de Magento.

1. Eliminar los cambios app/Mage.phpen el archivo de parche. Esto es lo que he hecho hasta ahora.
   Pros: el registro funciona como antes.
   Contras: al editar un archivo de parche, el registro no está protegido contra un posible exploit (pero esto debería ser de muy bajo riesgo). Cuando Magento publique una solución oficial, deberá revertirla y aplicar el parche original sin editar.
2. Agregue otro parche en la parte superior basado en la esencia de Piotr Kaminski: https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f . Piotr Kaminski es parte de Magento a cargo de la seguridad, por lo que esto viene directamente de la boca del caballo. Gist se compartió en Magento slack y probablemente terminará como SUPEE-11086 v1.1.
   Pros: esta es la manera de Magento
   Contras: tendrá que esperar a que esto se haga oficial, o asumir la responsabilidad y empaquetarlo como parche, lo que lo hará volver a tener que revertir una vez que haya terminado un parche oficial.
   Una ligera variación sería en lugar de agregar dos parches para editar el original con esos cambios.
3. Edite Zend_Validate_File_Extension::isValidy elimine la validación de existencia de archivos. hay una larga discusión en Magento LTS github - https://github.com/OpenMage/magento-lts/pull/648 . El isValidmétodo hace cosas que no se espera que haga, por lo que algunos miembros proponen solucionarlo. Mi opinión es que esta no es una buena solución, sí, el código es malo, pero estuvo allí para siempre y puede usarse en módulos / códigos personalizados. Por el contrario, lo peor que puede suceder es que no se verifique la existencia de los archivos.
   Pros: una solución bastante simple
   Contras: cambia un archivo de biblioteca y modifica su funcionalidad.
   Puede aplicar esto como un parche personalizado o reescribiendo toda la clase en el localgrupo de códigos.

Elegí editar el parche, y cuando llegue un v1.1, revertiré el parche editado, y aplicaré la versión original y después de esa corrección. Esto se adapta bien a nuestro proceso de construcción y política interna, puede ser diferente para usted. No importa lo que elija, es mejor aplicar este parche más temprano que tarde.

Algo de los aportes de la comunidad. Hay un nuevo Validator que se utiliza Zend_Validate_File_Extension como se muestra a continuación:

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 solución es editar el parche y simplemente eliminar los cambios de app / Mage.php. Desalentaría esta práctica, pero la situación es crítica".

Mi solución temporal era copiar lib/Zend/Validate/File/Extension.phpa app/code/local/Zend/Validate/File/Extension.phpy eliminar esta parte del código del isValid()método:

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

Se convertiría en ...

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

Cuando se lanza Magento 1.9.4.2, lo verifico nuevamente.

De hecho, el archivo no es legible, o no existe, no significa que el nombre del archivo no sea válido, ¿verdad?

Sugiero no cambiar el código central y usar una actualización 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';
");

Hay otro problema (que puede ser deliberado por el equipo de Magento) que impide la capacidad de escribir archivos de registro dentro de las subcarpetas. Por ejemplo:

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

En versiones anteriores, esa llamada habría creado un archivo en la ubicación:

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

Pero como hay una basename()llamada a función en el Mage::log()método, el archivo se escribe en:

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

Aquí está el código incriminado en app/Mage.php:

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

Incluso si no está especialmente relacionado con 1.9.4.1, el problema comenzó a ocurrir recientemente (en las últimas versiones 1.9.3.x) y es muy molesto cuando tiene que lidiar con muchos archivos de registro, a veces con el mismo nombre ( pero inicialmente en diferentes subcarpetas).

Como ese fragmento de código probablemente sea deliberado del equipo de Magento, creo que no hay ningún plan para solucionarlo en una versión posterior, lo que implica piratearlo para restaurar el comportamiento inicial ...