Mag :: log () nie działa na nowej aktualizacji Magento (1.9.4.1)

Po tej nowej aktualizacji (1.9.4.1) Mage :: log () nie działa. Najwyraźniej ma to coś wspólnego z Zend_Validate_File_Extensionlinią 819 na Mage.php, gdzie sprawdza, czy plik is_readable()jeszcze nie istnieje. Całą log()metodę odwróciłem do poprzedniej wersji i znów działa.

Jaki jest główny kanał, z którym mogę skontaktować się z zespołem Magento w celu zgłoszenia tego problemu?

Nadchodzi oficjalna łatka :) Nadal czekam na oficjalną łatkę ... :(

piotrekkaminski skomentował 13 godzin temu

To jest bieżąca oficjalna łatka, która zostanie przeniesiona do wcześniejszych wersji (powinna działać na najnowszych) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

^{Źródło: https://github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871}

Podsumuję wszystko, co do tej pory znalazłem na podstawie badań i interakcji z Magento, zarówno wsparcia, jak i Slacka, w odniesieniu do łatania za pomocą SUPEE-11086. Co można zrobić:

AKTUALIZACJA 2: Problem został rozwiązany w następnej PATCH SUPEE-11155 - https://magento.com/security/patches/supee-11155 . Jak zawsze przed zastosowaniem sprawdzania poprawek dla wątku możliwych problemów - Poprawka bezpieczeństwa SUPEE-11155 - Możliwe problemy? Podziękowania dla Aada Mathijssena za świetny komentarz.

Aktualizacja: oficjalna łatka jest dostępna na żądanie dla wersji EE. Zasadniczo jest to treść Piotra Kamińskiego opakowana jako plik łatki Magento.

1. Usuń zmiany dla app/Mage.phpw pliku poprawki. Tak właśnie zrobiłem.
   Plusy - logowanie działa jak poprzednio.
   Wady - edycja pliku łatki, logowanie nie jest chronione przed możliwym exploitem (ale to powinno być bardzo niskie ryzyko). Kiedy Magento wyda oficjalną poprawkę, będziesz musiał ją cofnąć i zastosować oryginalną, niezredagowaną łatkę.
2. Dodaj kolejną łatkę na górze w oparciu o istotę Piotra Kamińskiego - https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f . Piotr Kamiński jest częścią Magento odpowiedzialnego za bezpieczeństwo, więc pochodzi on prosto z pyska konia. Gist został udostępniony w Slack Magento i prawdopodobnie zakończy się jako SUPEE-11086 v1.1.
   Plusy -
   Wady Magento - Będziesz musiał poczekać, aż stanie się oficjalny, lub wziąć odpowiedzialność i spakować go jako łatkę, co przywróci cię do konieczności przywracania, gdy oficjalna łatka się pojawi.
   Niewielka zmiana byłaby możliwa zamiast dodawania dwóch łat w celu edycji oryginalnej z tymi zmianami.
3. Edytuj Zend_Validate_File_Extension::isValidi usuń sprawdzanie poprawności istnienia pliku. długa dyskusja w Magento LTS github - https://github.com/OpenMage/magento-lts/pull/648 . isValidSposób robi rzeczy, to nie można oczekiwać, aby zrobić, więc niektórzy członkowie proponują, aby to naprawić. Moim zdaniem nie jest to dobre rozwiązanie, tak, kod jest zły, ale był tam na zawsze i może być używany w niestandardowych modułach / kodzie. Wręcz przeciwnie, najgorsze, co może się zdarzyć, to to, że pliki nie są sprawdzane pod kątem istnienia.
   Plusy - raczej prosta poprawka
   Wady - zmienia plik biblioteki i poprawia jego funkcjonalność.
   Możesz zastosować to jako poprawkę niestandardową lub przepisując całą klasę w localpuli kodów.

Wybrałem edycję łatki, a kiedy pojawi się wersja 1.1, przywrócę edytowaną łatkę i zastosuję oryginalną wersję, a następnie poprawkę. Odpowiada to naszemu procesowi kompilacji i polityce wewnętrznej, może być dla Ciebie inaczej. Bez względu na to, co wybierzesz, lepiej zastosować tę łatkę wcześniej niż później.

Coś z wkładów społeczności. Jest nowy Walidator jest używany Zend_Validate_File_Extension zgodnie z poniższym:

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

„Rozwiązaniem jest edycja łatki i usunięcie zmian z aplikacji / Mage.php. Odradzałbym tę praktykę, ale sytuacja jest krytyczna”.

Moje rozwiązanie tymczasowe było skopiować lib/Zend/Validate/File/Extension.phpdo app/code/local/Zend/Validate/File/Extension.phpi usunąć tę część kodu z isValid()metody:

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

Stałoby się ...

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

Po wydaniu Magento 1.9.4.2 sprawdzam to ponownie.

W rzeczywistości plik nie jest czytelny lub nie istnieje, nie oznacza to, że nazwa pliku jest nieprawidłowa, prawda?

Sugeruję, aby nie zmieniać kodu podstawowego i używać takiej aktualizacji ( 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';
");

Istnieje inny problem (który może być celowy z zespołu Magento), który uniemożliwia zapisywanie plików dziennika w podfolderach. Na przykład:

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

We wcześniejszych wersjach to wywołanie utworzyłoby plik w lokalizacji:

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

Ale ponieważ basename()w Mage::log()metodzie jest wywołanie funkcji , plik jest zapisywany w:

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

Oto oskarżony kod w app/Mage.php:

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

Nawet jeśli nie jest to szczególnie związane z wersją 1.9.4.1, problem zaczął się ostatnio pojawiać (około najnowszych wersji 1.9.3.x) i jest bardzo denerwujący, gdy masz do czynienia z wieloma plikami dziennika, czasem o tej samej nazwie ( ale początkowo w różnych podfolderach).

Ponieważ ten fragment kodu jest prawdopodobnie zamierzony przez zespół Magento, myślę, że nie ma planu, aby go naprawić w kolejnej wersji, co oznacza zhakowanie go w celu przywrócenia początkowego zachowania ...