Mage :: log () non funziona sul nuovo aggiornamento di Magento (1.9.4.1)

Dopo questo nuovo aggiornamento (1.9.4.1), Mage :: log () non funziona. Apparentemente, ha qualcosa a che fare con la Zend_Validate_File_Extensionlinea 819 su Mage.php dove controlla se il file is_readable()prima ancora esiste. Ho invertito l'intero log()metodo alla versione precedente e funziona di nuovo.

Qual è il canale principale con cui posso contattare il team di Magento per segnalare questo problema?

Patch ufficiale in arrivo :) Ancora in attesa di patch ufficiale ... :(

piotrekkaminski ha commentato 13 ore fa

Questa è la patch ufficiale corrente che verrà trasferita alle versioni precedenti (dovrebbe funzionare sulle ultime) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

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

Riassumo tutto ciò che ho trovato finora basandomi sulla ricerca e l'interazione con Magento sia sul supporto che su Slack per quanto riguarda il patching con SUPEE-11086. Cosa si può fare:

AGGIORNAMENTO 2: il problema è stato risolto nel prossimo PATCH SUPEE-11155 - https://magento.com/security/patches/supee-11155 . Come sempre prima di applicare il patch check per i possibili problemi thread - Security Patch SUPEE-11155 - Possibili problemi? Grazie ad Aad Mathijssen per l'ottimo commento.

Aggiornamento: una patch ufficiale è disponibile su richiesta per la versione EE. Fondamentalmente, è l'essenza di Piotr Kaminski racchiusa come file patch Magento.

1. Elimina le modifiche app/Mage.phpnel file patch. Questo è quello che ho fatto finora.
   Pro: la registrazione funziona come prima.
   Contro: modificando un file patch, la registrazione non è protetta da un possibile exploit (ma questo dovrebbe essere a rischio molto basso). Quando Magento rilascia una correzione ufficiale, dovrai ripristinarla e applicare la patch originale non modificata.
2. Aggiungi un'altra patch in cima basata sull'essenza di Piotr Kaminski - https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f . Piotr Kaminski fa parte di Magento responsabile della sicurezza, quindi questo viene direttamente dalla bocca del cavallo. Gist è stato condiviso in Magento e probabilmente finirà come SUPEE-11086 v1.1.
   Pro - Questo è il modo Magento
   Contro - Dovrai aspettare che questo diventi ufficiale, o assumerti la responsabilità e impacchettarlo come patch tu stesso, che ti riporterà a dover ripristinare una volta che una patch ufficiale è attiva.
   Una leggera variazione sarebbe invece di aggiungere due patch per modificare quella originale con quelle modifiche.
3. Modifica Zend_Validate_File_Extension::isValide rimuovi la convalida dell'esistenza del file. c'è una lunga discussione in Magith LTS github - https://github.com/OpenMage/magento-lts/pull/648 . Il isValidmetodo fa cose che non ci si aspetta che faccia, quindi alcuni membri propongono di risolverlo. La mia opinione è che questa non è una buona soluzione, sì, il codice è cattivo, ma è stato lì per sempre e può essere utilizzato in moduli / codice personalizzati. Al contrario, il peggio che può accadere è che i file non vengono controllati per l'esistenza.
   Pro - una soluzione piuttosto semplice
   Contro - cambia un file di libreria e ne modifica la funzionalità.
   Puoi applicarlo come patch personalizzata o riscrivendo l'intera classe nel localpool di codici.

Ho scelto di modificare la patch e, quando arriva una v1.1, ripristinerò la patch modificata e applicherò la versione originale e dopo quella correzione. Questo si adatta bene al nostro processo di costruzione e alla politica interna, potrebbe essere diverso per te. Indipendentemente da ciò che hai scelto, è meglio applicare questa patch prima che dopo.

Qualcosa dagli input della community. C'è un nuovo validatore utilizzato Zend_Validate_File_Extension come di seguito:

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 soluzione sta modificando la patch e rimuovendo semplicemente le modifiche dall'app / Mage.php scoraggerei fortemente questa pratica, ma la situazione è critica".

La mia soluzione temporanea era quello di copiare lib/Zend/Validate/File/Extension.phpa app/code/local/Zend/Validate/File/Extension.phpe rimuovere questa parte del codice dal isValid()metodo:

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

Diventerebbe ...

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

Quando viene rilasciato Magento 1.9.4.2, lo ricontrollo.

In effetti, il file non è leggibile o non esiste, non significa che il nome del file non sia valido, giusto?

Suggerisco di non modificare il codice principale e utilizzare un aggiornamento come questo ( 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';
");

C'è un altro problema (che può essere deliberato dal team di Magento) che impedisce la possibilità di scrivere file di registro all'interno delle sottocartelle. Per esempio:

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

Nelle versioni precedenti, quella chiamata avrebbe creato un file nella posizione:

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

Ma poiché basename()nel Mage::log()metodo è presente una chiamata di funzione , il file viene scritto in:

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

Ecco il codice incriminato in app/Mage.php:

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

Anche se non è particolarmente correlato a 1.9.4.1, il problema ha iniziato a verificarsi di recente (intorno alle ultime versioni 1.9.3.x) ed è molto fastidioso quando si devono gestire molti file di registro, a volte con lo stesso nome ( ma inizialmente in diverse sottocartelle).

Dato che quel pezzo di codice è probabilmente deliberato dal team di Magento, penso che non ci siano piani per risolverlo in un'ulteriore versione, il che implica hackerarlo per ripristinare il comportamento iniziale ...