Mage :: log () funktioniert nicht bei neuem Magento-Update (1.9.4.1)

Nach diesem neuen Update (1.9.4.1) funktioniert Mage :: log () nicht mehr. Anscheinend hat es etwas mit Zend_Validate_File_ExtensionZeile 819 bei Mage.php zu tun, wo es prüft, ob die Datei, is_readable()bevor sie überhaupt existiert. Ich habe die gesamte log()Methode auf die vorherige Version zurückgesetzt und sie funktioniert wieder.

Über welchen Hauptkanal kann ich mich an das Magento-Team wenden, um dieses Problem zu melden?

Offizieller Patch eingetroffen :) Ich warte noch auf den offiziellen Patch ... :(

piotrekkaminski hat das kommentiert vor 13 Stunden

Dies ist der aktuelle offizielle Patch, der auf frühere Versionen portiert wird (dies sollte auf den neuesten Versionen funktionieren). Https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

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

Ich werde alles zusammenfassen, was ich bisher aufgrund von Recherchen und Interaktionen mit Magento, sowohl Support als auch Slack in Bezug auf das Patchen mit SUPEE-11086 gefunden habe. Was kann getan werden:

UPDATE 2: Das Problem wird im nächsten PATCH SUPEE-11155 behoben - https://magento.com/security/patches/supee-11155 . Wie immer, bevor Sie den Patch anwenden, überprüfen Sie den Thread auf mögliche Probleme. - Sicherheitspatch SUPEE-11155 - Mögliche Probleme? Vielen Dank an Aad Mathijssen für den tollen Kommentar.

Update: Ein offizieller Patch für die EE-Version ist auf Anfrage erhältlich. Grundsätzlich ist es Piotr Kaminskis Kern als Magento-Patchdatei verpackt.

1. Löschen Sie die Änderungen für app/Mage.phpin der Patch-Datei. Das habe ich bisher getan.
   Die Protokollierung funktioniert wie bisher.
   Bei der Bearbeitung einer Patch-Datei ist die Protokollierung nicht vor einem möglichen Exploit geschützt (dies sollte jedoch ein sehr geringes Risiko darstellen). Wenn Magento ein offizielles Update veröffentlicht, müssen Sie es zurücksetzen und den ursprünglichen, unbearbeiteten Patch anwenden.
2. Fügen Sie einen weiteren Patch hinzu, der auf Piotr Kaminskis Kern basiert - https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f . Piotr Kaminski ist Teil von Magento und für die Sicherheit zuständig. Das kommt also direkt aus dem Maul des Pferdes. Gist wurde in Magento Slack geteilt und wird wahrscheinlich als SUPEE-11086 v1.1 enden.
   Vorteile - Dies ist der Weg von Magento
   Nachteile - Sie müssen warten, bis dies offiziell wird, oder Sie übernehmen die Verantwortung und packen es selbst als Patch, wodurch Sie wieder zurückkehren müssen, sobald ein offizieller Patch verfügbar ist.
   Eine leichte Variation wäre, anstatt zwei Patches hinzuzufügen, um das Original mit diesen Änderungen zu bearbeiten.
3. Bearbeiten Zend_Validate_File_Extension::isValidund Entfernen der Überprüfung des Vorhandenseins von Dateien. In Magento LTS github gibt es eine lange Diskussion - https://github.com/OpenMage/magento-lts/pull/648 . Die isValidMethode führt Dinge aus, die nicht erwartet werden. Einige Mitglieder schlagen daher vor, sie zu beheben. Meine Meinung ist, dass dies keine gute Lösung ist, ja Code ist schlecht, aber es war für immer da und kann in benutzerdefinierten Modulen / Code verwendet werden. Im Gegenteil, das Schlimmste, was passieren kann, ist, dass Dateien nicht auf Existenz überprüft werden.
   Vorteile - eine ziemlich einfache Lösung
   Nachteile - ändert eine Bibliotheksdatei und ändert ihre Funktionalität.
   Sie können dies entweder als benutzerdefinierten Patch oder durch Umschreiben der gesamten Klasse im Codepool anwenden local.

Ich habe mich entschieden, den Patch zu bearbeiten, und wenn eine v1.1 kommt, werde ich den bearbeiteten Patch zurücksetzen und die Originalversion und danach den Fix anwenden. Dies passt gut zu unserem Erstellungsprozess und unseren internen Richtlinien. Es könnte für Sie anders sein. Egal, für was Sie sich entschieden haben, es ist besser, diesen Patch früher als später anzuwenden.

Etwas von Community Inputs. Es gibt einen neuen Validator, der Zend_Validate_File_Extension wie folgt verwendet:

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

"Die Lösung besteht darin, den Patch zu bearbeiten und nur die Änderungen aus app / Mage.php zu entfernen. Ich würde von dieser Vorgehensweise dringend abraten, aber die Situation ist kritisch."

Meine vorübergehende Lösung bestand darin , diesen Teil des Codes zu kopieren und aus der Methode lib/Zend/Validate/File/Extension.phpzu entfernen :app/code/local/Zend/Validate/File/Extension.phpisValid()

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

Es würde ...

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

Wenn Magento 1.9.4.2 veröffentlicht wird, überprüfe ich das noch einmal.

Tatsächlich bedeutet die Tatsache, dass die Datei nicht lesbar ist oder nicht existiert, nicht, dass der Dateiname ungültig ist, oder?

Ich empfehle, den Core-Code nicht zu ändern und ein Update wie dieses zu verwenden ( 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';
");

Es gibt ein anderes Problem (das möglicherweise vom Magento-Team beabsichtigt ist), das das Schreiben von Protokolldateien in Unterordnern verhindert. Beispielsweise:

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

In früheren Versionen hätte dieser Aufruf eine Datei am Speicherort erstellt:

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

Da es jedoch einen basename()Funktionsaufruf in Mage::log()method gibt, wird die Datei geschrieben unter:

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

Hier ist der belastete Code in app/Mage.php:

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

Auch wenn es sich nicht speziell um 1.9.4.1 handelt, trat das Problem in letzter Zeit auf (etwa in der neuesten Version 1.9.3.x) und ist sehr ärgerlich, wenn Sie mit vielen Protokolldateien, manchmal mit demselben Namen, arbeiten müssen ( aber zunächst in verschiedenen Unterordnern).

Da dieser Teil des Codes wahrscheinlich vom Magento-Team beabsichtigt ist, gibt es meines Erachtens keinen Plan, ihn in einer weiteren Version zu beheben, was impliziert, ihn zu hacken, um das ursprüngliche Verhalten wiederherzustellen ...