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


23

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?


1
@PiotrSiejczuk Eso no funciona para nuevos archivos de registro. Su segundo comentario implica que la capacidad de cambiar la configuración de rotación de registros hace que esto no sea un problema grave y estoy completamente en desacuerdo. Su primer comentario implica que esto probablemente solo sea un problema para OP, o en algún tipo de caso límite, y estoy muy en desacuerdo con eso también. Entiendo completamente por qué Magento no habría notado este error, pero estas implicaciones son lo contrario de lo que se necesita aquí (ya sea que sean deliberadas o no).
toon81

3
Hay muchas situaciones en las que esto es problemático: instalaciones limpias (en este caso, system.log aún no existe), creación / instalación de módulos locales y de terceros que inician sesión en archivos de registro personalizados, registran configuraciones que no crean explícitamente / mantenga el archivo de registro original.
Aad Mathijssen

3
Sí, el registro es esencial para cada software, me pregunto por qué lo han dejado pasar. Mi sueño es que cuando llegue 2020 y el equipo de Magento deje de admitir 1.x, carguen su última versión en un repositorio oficial de Git para que la comunidad pueda mantenerla actualizada
rodrigoriome

1
@cslogic "Mi sueño es que cuando llegue 2020 y el equipo de Magento deje de admitir 1.x, carguen su última versión en un repositorio oficial de Git para que la comunidad pueda mantenerla actualizada" => Ya se hizo con OpenMage LTS: github. com / OpenMage / magento-lts
Frédéric MARTINEZ

1
@ FrédéricMARTINEZ eso es gracioso, Ben Marks en realidad me contó sobre ese repositorio unos 30 minutos antes de que leyera tu comentario ... Gracias de todos modos, lo
echaré

Respuestas:



7

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.


1
A partir del 25 de junio, Magento ha lanzado SUPEE-11155, Magento Commerce 1.14.4.2 y Magento Open Source 1.9.4.2 que incluyen una solución para este problema. Esencialmente, se ha incluido el parche de Piotr Kaminski.
Aad Mathijssen

4

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


De hecho, es una mala práctica, pero no puedo sobrevivir sin iniciar sesión. Espero que Adobe pueda arreglarlo pronto
rodrigoriome

Sí, tuve que recrear todos los archivos de registro porque el script logrotator estaba borrando archivos y creando archivos comprimidos. Necesitaré encontrar un mejor script de magento que no solucione esto.
Kalvin Klien

1
@KalvinKlien: ¿Intentaste con: la opción copytruncate de logrotate? "Truncar el archivo de registro original a tamaño cero en su lugar después de crear una copia, en lugar de mover el archivo de registro anterior y, opcionalmente, crear uno nuevo. Se puede usar cuando no se puede indicar a algún programa que cierre su archivo de registro y, por lo tanto, puede continuar escribiendo ( agregar) al archivo de registro anterior para siempre. Tenga en cuenta que hay un intervalo de tiempo muy pequeño entre copiar el archivo y truncarlo, por lo que podrían perderse algunos datos de registro. Cuando se utiliza esta opción, la opción de creación no tendrá efecto, ya que el archivo de registro anterior permanece en su lugar ".
Piotr Siejczuk

Gracias @PiotrSiejczuk! Usé esto: / ruta / var / log / * log {rotar 7 copiar truncar diariamente comprimir missingok notifempty}
Kalvin Klien

1

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?



0

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


Para ese problema de subcarpeta no tengo idea, pero para el problema de registro real estamos representando ese fragmento de código gist.github.com/piotrekkaminski/…
rodrigoriome
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.