Magento 1.x SUPEE-11086 Bug – Mage::log stops writing data

Brian

5 years ago

It’s good to keep your Magento installation up to date with security patches. But like usual, be ready to catch a bug or two from them…

With SUPEE-11086 I’ve so far found that calls to Mage::log no longer write data to the log files. They seem to have crippled this function by accident for my installation…

Contents

1 Source of the Bug
2 Solution (let’s start writing data again!)
3 Tested Version
4 Magento’s Support / Response to this Bug
5 Magento Ignored Existing Code?
6 Resolution / Update

Source of the Bug

In app/Mage.php they made this change:

// Validate file extension before save. Allowed file extensions: log, txt, html, csv
-        if (!self::helper('log')->isLogFileExtensionValid($file)) {
+        $_allowedFileExtensions = explode(
+            ',',
+            (string) self::getConfig()->getNode('dev/log/allowedFileExtensions', Mage_Core_Model_Store::DEFAULT_CODE)
+        );
+        $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);
+        $logDir = self::getBaseDir('var') . DS . 'log';
+        if (!$logValidator->isValid($logDir . DS . $file)) {
         return;
    }

// Validate file extension before save. Allowed file extensions: log, txt, html, csv

- if (!self::helper('log')->isLogFileExtensionValid($file)) {

+ $_allowedFileExtensions = explode(

+ ',',

+ (string) self::getConfig()->getNode('dev/log/allowedFileExtensions', Mage_Core_Model_Store::DEFAULT_CODE)

+ );

+ $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);

+ $logDir = self::getBaseDir('var') . DS . 'log';

+ if (!$logValidator->isValid($logDir . DS . $file)) {

return;

}

This change looks to your stores configuration for a list of what file extensions are approved for logging (comma separated). However this configuration doesn’t exist… It should be in the database (or I believe could be defined in XML).

Magento could/should have added an option to configure this is the Mage Admin in my mind with this patch.

Solution (let’s start writing data again!)

The solve is actually quite simple. We need to add the configuration to the database and clear the cache.

Add entry to the database (core_config_data table)
- INSERT INTO core_config_data VALUES ( NULL, 'default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv' );
Clear the object cache
- via the Magento admin or command line
Verify log files are writing again (look at timestamps)
- ls -lrt var/log/ | tail

Tested Version

Magento Enterprise Edition 1.14.2.0 with all security patches applied.

I applied PATCH_SUPEE-11086_EE_1.14.2.4_v1-2019-03-26-03-11-57.sh when applying the SUPEE-11086 patch.

Magento’s Support / Response to this Bug

I have an open ticket with Magento Support. I’ll update if/when I hear a response.

Magento Ignored Existing Code?

Odd/sad that Magento didn’t reuse existing code for validating log file extensions that they added via SUPEE-10415 in late 2017.

app/code/core/Mage/Log/Helper/Data.php

/**
 * Checking if file extensions is allowed. If passed then return true.
 *
 * @param $file
 * @return bool
 */
public function isLogFileExtensionValid($file)
{
    $result = false;
    $validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);
    if ($validatedFileExtension && in_array($validatedFileExtension, $this->_allowedFileExtensions)) {
        $result = true;
    }

    return $result;
}

/**

* Checking if file extensions is allowed. If passed then return true.

* @param $file

* @return bool

public function isLogFileExtensionValid($file)

{

$result = false;

$validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);

if ($validatedFileExtension && in_array($validatedFileExtension, $this->_allowedFileExtensions)) {

$result = true;

}

return $result;

}

Resolution / Update

It turns out this was a case of user error…. (not sure how I could have done that!!! ha!) But others may run into this as well and thus I’m leaving this post active.

I have the main codebase in one git repo. I have a second git repo for configuration which includes the file app/etc/config.xml which was part of the patch. But when I deployed the change this configuration did not get pushed live. Once I updated the XML file and I removed my added config from the database all still worked as expected (and flushed cache of course).