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

23

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?

magento-1.9 log bug magento-1.9.4.1 rodrigoriome
źródło
1
@PiotrSiejczuk To nie działa w przypadku nowych plików dziennika. Drugi komentarz sugeruje, że możliwość zmiany konfiguracji rotacji logów sprawia, że ​​nie jest to poważny problem i całkowicie się z tym nie zgadzam. Twój pierwszy komentarz sugeruje, że jest to prawdopodobnie tylko problem dla OP lub w jakimś przypadku krawędzi, i ja też bardzo się z tym nie zgadzam. Całkowicie rozumiem, dlaczego Magento nie zauważył tego błędu, ale te implikacje są przeciwieństwem tego, co jest tu potrzebne (czy są celowe, czy nie).
toon81
3
Jest wiele sytuacji, w których jest to problematyczne: czyste instalacje (w tym przypadku plik system.log jeszcze nie istnieje), tworzenie / instalacja modułów lokalnych i zewnętrznych, które logują się do niestandardowych plików dziennika, tworzenie konfiguracji, które nie jawnie tworzą / zachowaj oryginalny plik dziennika.
Aad Mathijssen
3
Tak, logowanie jest niezbędne w każdym oprogramowaniu. Zastanawiam się, dlaczego to pozwoliło. Moim marzeniem jest to, że kiedy nadejdzie rok 2020 i zespół Magento przestanie wspierać 1.x, przesyłają swoją ostatnią wersję na oficjalne repozytorium Git, aby społeczność mogła ją aktualizować
rodrigoriome
1
@cslogic „Moim marzeniem jest to, że kiedy nadejdzie rok 2020 i zespół Magento przestanie wspierać 1.x, przesyłają swoją ostatnią wersję na oficjalne repozytorium Git, aby społeczność mogła ją aktualizować” => Już zrobione z OpenMage LTS: github. com / OpenMage / magento-lts
Frédéric MARTINEZ
1
@ FrédéricMARTINEZ, że to zabawne, Ben Marks powiedział mi o tym repozytorium około 30 minut, zanim przeczytam ci komentarz. Dzięki, spójrz na to
rodrigoriome

Odpowiedzi:

7

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.

Dimitar Iwanow
źródło
1
Od 25 czerwca Magento wydało SUPEE-11155, Magento Commerce 1.14.4.2 i Magento Open Source 1.9.4.2, które zawierają poprawkę dotyczącą tego problemu. Zasadniczo uwzględniono łatkę Piotra Kamińskiego.
Aad Mathijssen
4

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

Piotr Siejczuk
źródło
To rzeczywiście zła praktyka, ale nie mogę przetrwać bez logowania. Mam nadzieję, że Adobe może to naprawić wkrótce
rodrigoriome
tak, musiałem odtworzyć wszystkie pliki dziennika, ponieważ skrypt logrotator kasował pliki i tworzył z nich zamki błyskawiczne. Będę musiał znaleźć lepszy skrypt Magento nie naprawi tego.
Kalvin Klien
1
@KalvinKlien: Czy próbowałeś / -aś z: copytruncate logrotate? „Obetnij oryginalny plik dziennika do zera po utworzeniu kopii, zamiast przenosić stary plik dziennika i opcjonalnie utworzyć nowy. Można go użyć, gdy nie można nakazać programowi, aby zamknął plik dziennika, a zatem może kontynuować zapisywanie ( dołączanie) do poprzedniego pliku dziennika na zawsze. Należy pamiętać, że istnieje bardzo mały przedział czasu między kopiowaniem pliku a jego obcinaniem, więc niektóre dane rejestrowania mogą zostać utracone. Gdy ta opcja jest używana, opcja tworzenia nie będzie działać, ponieważ stary plik dziennika pozostaje na swoim miejscu ".
Piotr Siejczuk
Dzięki @PiotrSiejczuk! Użyłem tego: / path / var / log / * log {rotate 7 copytruncate dzienny kompres brakującyok notifempty}
Kalvin Klien
1

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?

Ricardo Martins
źródło
1

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';
");
Mehdi Chaouch
źródło
0

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

Antoine ETIEVANT
źródło
W przypadku tego podfolderu nie mam pojęcia, ale w przypadku rzeczywistego problemu z logowaniem reprezentujemy ten fragment kodu gist.github.com/piotrekkaminski/...
rodrigoriome