Poprawka bezpieczeństwa SUPEE-8788 - Możliwe problemy?

108

Najnowsza poprawka bezpieczeństwa Magento 1 SUPEE-8788 zawiera 17 aktualizacji APPSEC , dlatego bardzo ważne jest, aby ją jak najszybciej zastosować. Z drugiej strony istnieje wiele potencjalnych przerw w kompatybilności wstecznej, a biorąc pod uwagę historię łat w ciągu ostatniego roku, nie zastosowałbym tego niedbale.

Dobrą rzeczą jest to, że tym razem nie ma żadnych szablonów nakładki, więc wygląda na to, że nie musimy łatać wszystkich naszych motywów. Dotyczy to tylko Magento 1.8 lub wyższej.

Niemniej jednak: czy napotkałeś jakieś problemy ze zgodnością lub błędy po zastosowaniu łatki?

Fabian Schmengler
źródło
6
„nie ma żadnych szablonów nakładki” - nie jest poprawny dla starszych wersji Magento. Na przykład łatka 1.7.0.2 zmienia 9 plików szablonów frontend / base / default.
Kristof at Fooman
2
Dla każdego, kto ma problemy z aktualizacjami łatki .swf, po prostu usunąłem wiersze 5951-9818 z łatki i ręcznie usunąłem pliki .swf z /skin/adminhtml/default/default/media- ponieważ to i tak wszystko działało.
Liam McArthur
nie jestem pewien, dlaczego, ale po instalacji 8788 w wersji 1.8.0.0 łatka 7405 zgłasza, że ​​NIE została zainstalowana. podczas gdy wcześniej zainstalowano v1 i v1.1
MagenX
2
@ srinivas czy usunąłeś folder multimediów z tej ścieżki skin / adminhtml / default / default?
Priya Ponnusamy

Odpowiedzi:

107

Ważne notatki

Należy pamiętać, że 1.9.3 różni się od 1.9.2.4 + SUPEE-8788. Oto różnica między nimi: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Aktualizacja 14 października: wersja 2 łatki została wydana (patrz poniżej) Od 13 października łatki od 1.5.x do 1.8.x zostały usunięte ze strony Magento z powodu niezgodności z poprzednimi łatkami (patrz poniżej):

https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/td-p/50434/highlight/false/page/2

V3 łatki

Ta nowa wersja jest tylko dla Magento EE 1.13.0.x

Zastosuj V3:

  • przywróć SUPEE 1533 (jeśli jest zainstalowany)
  • zainstaluj SUPEE 3941 (jeśli nie jest zainstalowany)
  • zainstaluj SUPEE 8788 v3

V2 łatki

Zastosuj V2:

  • przywrócić SUPEE 8788 v1
  • przywróć SUPEE 1533 (jeśli jest zainstalowany)
  • zainstaluj SUPEE 3941 (jeśli nie jest zainstalowany)
  • zainstaluj SUPEE 8788 v2

DemacMedia opracowało przydatny skrypt bash do automatyzacji procesu powyżej. Można go znaleźć tutaj: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Szczegóły dotyczące łatki

Po zagłębieniu się w łatkę tutaj są interesujące części (łatanie z 1.9.2.4):

  • Mage_Adminhtml_Block_Media_Uploaderzostał zastąpiony przez, Mage_Uploader_Block_Multiplewięc jest pełny Mage_Uploadermoduł, który upuszcza obsługę Flasha . Stary blok jest teraz przestarzały i rozszerza nowy blok.
  • Nadal dotyczące przesyłającej, moduł został refactored aby obsłużyć nowy non-Flash Uploader. Używa jako bloku przesyłania zamiast szablonów.Mage_DownloadableMage_Uploader_Block_Single
  • W wyniku tej zmiany, t on pliki SWF skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swfi skin/adminhtml/default/default/media/uploaderSingle.swfzostały usunięte.
  • Kontroler usuwania adresów jest teraz chroniony kluczem formularza bezpośrednio getDeleteUrlz poziomuMage_Customer_Block_Address_Book
  • Kontroler życzeń usuwanie pozycja jest teraz zabezpieczona kluczem formy poprzez getRemoveUrlodMage_Wishlist_Helper_Data
  • Metoda płatności Paypal Express zapewnia teraz, że używany e-mail klienta istnieje w Magento podczas sprawdzania i rejestracji nowego użytkownika. (zrozum: nowy użytkownik jest tworzony przed przetworzeniem nowej oferty)
  • Metody płatności za pomocą klienta cURL / HTTP mają teraz CURLOPT_SSL_VERIFYHOSTwartość 2 (wcześniej było 0), a CURLOPT_SSL_VERIFYPEERflaga jest teraz dodawana do wywołań cURL. Flagę Verify Peer można włączyć / wyłączyć poprzez konfigurację metody płatności poprzez menu rozwijane Włącz weryfikację SSL.
  • Mage_Http_Client_Curlteraz CURLOPT_SSL_VERIFYPEERustawiono na true (wcześniej było fałszem) , uważaj, jeśli korzystasz z dowolnego niestandardowego modułu.
  • Maksymalne wymiary zdjęć produktów można teraz konfigurować w konfiguracji. Uwaga: jeśli prześlesz zbyt duże obrazy, może to spowodować zabawny komunikat o błędzie: Niedozwolony format pliku w Magento 1.9.2.2 po przesłaniu poprawki

Znane problemy z SUPEE-8788 v2

Znane problemy z SUPEE-8788 v1

Znane problemy 1.9.3.0

Edycja: ponieważ lista jest długa i w tej odpowiedzi jest dość nie na temat (ponieważ nie jest związana z SUPEE-8788), możesz odnieść się do tego postu, aby uzyskać listę znanych problemów 1.9.3.0: https: //magento.stackexchange. com / a / 140826/2380

Raphael at Digital Pianism
źródło
1
Dzięki za obszerną listę! Jedno pytanie: czy jesteś pewien, że problem wyszukiwania pełnotekstowego dotyczy poprawki SUPEE-8788? Nie mogę znaleźć żadnych zmian związanych z tą funkcjonalnością.
Aad Mathijssen
1
@MageDev zapoznaj się z trzecim komentarzem w pytaniu;)
Raphael at Digital Pianism
1
Jeśli narzędzie do przesyłania produktów nie działa po pomyślnym zastosowaniu poprawki i korzystasz z popularnej wtyczki CreareSEO, poprawka będzie musiała zostać zastosowana również github.com/adampmoss/CreareSEO/pull/78
joesk
1
Zauważyłem, że wspomniałeś: „Metoda płatności Paypal Express zapewnia teraz, że używany adres e-mail klienta istnieje w Magento”. Czy to oznacza, że ​​Gość nie może dokonać płatności za pomocą usługi PayPal express? Musisz być zarejestrowanym użytkownikiem? Czy coś mi umknęło?
Ikona
1
Niektóre rozszerzenia innych firm, które korzystały ze starego programu do przesyłania, są po prostu zepsute po zastosowaniu poprawki. Np. „Magic 360” dodaje zakładkę do zakładek ze szczegółowymi informacjami o produkcie. Po poprawce nie będziesz mógł zobaczyć / edytować szczegółów produktu. Zauważyłem ten problem dla programisty rozszerzenia na Magento connect ( magentocommerce.com/magento-connect/… ).
DarkCowboy,
29

Podczas stosowania poprawki może wystąpić błąd:

checking file skin/adminhtml/default/default/media/flex.swf
checking file skin/adminhtml/default/default/media/uploader.swf
checking file skin/adminhtml/default/default/media/uploaderSingle.swf
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
checking file skin/adminhtml/default/default/xmlconnect/boxes.css

Łatka 8788 zawiera zawartość binarną. Ponieważ Magento nie udostępnia żadnych bezpośrednich linków do pobierania (od tego czasu nienawidzę tej zasady), musisz pobrać poprawkę na swój komputer i przesłać ją za pomocą aplikacji do przesyłania plików (takiej jak WinSCP w systemie Windows) na swój serwer. Na przykład WinSCP prześle w trybie TEXT (WinSCP domyślnie obsługuje pliki * .sh jako tekst).

Tak więc obejściem tego jest spakowanie / spakowanie pliku łatki i rozpakowanie / rozpakowanie ponownie na serwerze. gotowe.


Przepraszam, nie miałem sposobu, aby na to odpowiedzieć

  1. Pobierz poprawną wersję Magento (np .: CE 1.9.1.0)
  2. Zastąp następujące pliki pobraną lokalizacją

skin / adminhtml / default / default / media / flex.swf skin / adminhtml / default / default / media / uploader.swf skin / adminhtml / default / default / media / uploaderSingle.swf

  1. Uruchom łatkę

Pracował dla mnie


infabo
źródło
10
Czy czytałeś pytanie PO? fschmengler zapytał: „Mimo to: Czy napotkałeś jakieś problemy ze zgodnością lub błędy PO nałożeniu łatki?” Napotkałem ten problem PODCZAS nakładania łatki. Myślę, że sens tego wątku polega na udokumentowaniu możliwych błędów SUPEE-8788. Obejmuje to - IMHO - problemy z samą łatką.
infabo
Pracowałem przysmak, dzięki! Czy najlepiej to zrobić również dla WSZYSTKICH przyszłych poprawek Magento?
KiwisTasteGood
lub po prostu dos2unix PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh
fbtb 13.10.16
Generalnie nie było to wcześniej konieczne i zakładam, że nie będzie to konieczne w przyszłości. Sądzę, że pliki SWF przesyłające były jedynymi plikami binarnymi dostarczanymi z Magento 1.x - teraz ich nie ma. Nie spodziewam się, że w przyszłości pojawią się takie problemy.
infabo
3
Podczas korzystania z FileZilla do przesyłania .shpliku łaty do katalogu głównego Magento, ustaw typ przesyłania na binaryprzed przesłaniem pliku łatki. Odniesienie
ForMat
25

Jeśli wcześniej zastosowałeś SUPEE-1533, łatka się nie powiedzie app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

Rozwiązałem to przez ...

  1. Ręcznie przywróć zmiany wprowadzone do tego pliku przez SUPEE-1533
  2. Zastosuj SUPEE-8788
  3. Ręcznie przywróć zmiany wprowadzone do tego pliku przez SUPEE-1533

Usunięcie zmiany z SUPEE-8788 jest niebezpieczne, ponieważ plik łatki zawiera dane binarne, a zapisanie go w edytorze może powodować problemy (kolejna gotcha).

mpchadwick
źródło
Rozumiem, że przywróciłeś oryginalną łatkę 1533, zainstalowałeś SUPEE 8788, a następnie ponownie zainstalowałeś 1533 ?? Czy dobrze rozumiem?
Ikona
Mam również problem z FAILED HUNK w aplikacji 28 / design / frontend / base / default / template / review / form.phtml
Ikona
9
Zastanawiam się, dlaczego, kiedy poświęcamy czas na prawidłowe stosowanie oficjalnych łat przyrostowych, dostajemy za to karę, ponieważ musimy dokonywać ręcznych poprawek, gdy łatki nie działają po zastosowaniu wcześniej dostarczonych łat. Bardzo dziwne podejście.
Jon Holland
1
Większość wersji poniżej 1.9 z zainstalowanym SUPEE 1533 nie może poprawnie zainstalować poprawki. SUPEE 8788 nie jest kompatybilny z 1533
Ikona
2
@JonHolland Ponieważ, cóż, to Magento.
Agop
25

Oto podsumowanie tego, co do tej pory spotkałem (i innych), staram się to uporządkować, dodając lub łącząc wszystko, czego brakuje, post jest Wiki Społeczności:

Przyczyny nieudanej łatki

Jeśli zobaczysz komunikat „BŁĄD: poprawki nie można pomyślnie zastosować / przywrócić”, poszukaj „Hunk # 1 FAILED” w komunikatach dziennika, aby sprawdzić, w którym pliku błąd się nie powiódł.

  • Najwyraźniej v2 łatki dla Magento 1.7 oczekuje, że pojawi się SUPEE-3941, chociaż istnieje tylko dla Magento 1.8 i 1.9 . Jeśli korzystasz z Magento 1.7 i widzisz błędy związane z plikami w downloader, pobierz SUPEE-3941 dla 1.8 i zastosuj go w 1.7, powinno działać. Zobacz temat komentarza tutaj: Problem z poprawką bezpieczeństwa SUPEE 8788
  • W wersjach Magento, w których wcześniej stosowano SUPEE-1533, poprawka kończy się niepowodzeniem, app/code/core/Mage/Adminhtml/controllers/DashboardController.phpponieważ na plik mają wpływ zarówno łatki, jak i SUPEE-8788 (niepoprawnie!) Zakłada, że ​​wersja niepakowana jest obecna. Jest to nadal prawdą w przypadku wersji 2 łatki! Wersja 2 zawiera zmiany w stosunku do SUPEE-1533, więc jeśli zainstalowałeś go wcześniej, nadal musisz go cofnąć, ale nie musisz go później ręcznie stosować ponownie.

  • Jeśli usunąłeś katalog „downloader” lub zmieniłeś jego nazwę, łata się nie powiedzie, ponieważ łata plik w downloaderze. Najłatwiejszym sposobem obejścia tego problemu jest przywrócenie oryginalnego katalogu downloadera, zastosowanie poprawki, a następnie usunięcie katalogu ponownie. Alternatywnie możesz również usunąć instrukcje dotyczące downloader/lib/Mage/HTTP/Client/Curl.phpłatki.

  • Inne komunikaty „Hunk FAILED” są zwykle spowodowane zmianami w podstawowych plikach lub brakiem poprzednich poprawek. Upewnij się, że wszystkie poprzednie łaty dla twojej wersji Magento są zainstalowane i że nie wprowadziłeś zmian w podstawowych plikach.

  • Innym częstym problemem jest to, że łatka nie usuwa .swfplików z powodu ich zawartości binarnej. Błąd będzie wyglądał następująco:

    checking file skin/adminhtml/default/default/media/uploaderSingle.swf
    Reversed (or previously applied) patch detected!  Assume -R? [n]
    Apply anyway? [n]
    Skipping patch.
    1 out of 1 hunk ignored
    

    lub tak

    Patching file skin/adminhtml/default/default/media/uploader.swf using Plan A...
    No such line 2 in input file, ignoring
    Empty context always matches.
    Hunk #1 failed at 0.
    1 out of 1 hunks failed while patching skin/adminhtml/default/default/media/uploader.swf
    Hmm...  The next patch looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    

    lub tak:

    Checking if patch can be applied/reverted successfully...
    /bin/patch: **** malformed patch at line 5790: ?rM]M??????&X㔮??v??Q;r?N?qJ??Y???I0?Y??4??'?????9?.??X?Ǒ?{??ax!G???I???q?u|????թ??????|
                                                   h??o?V@??|? ?g?H aꪭ??Ю???,I"?ğ????.??    yI?I\????)?X?
                         ?p???*?e?q?K8<DqD?H;|?
    ERROR: Patch can't be applied/reverted successfully.
    

    Możliwe odpowiedzi są podane w tej odpowiedzi przez @infabo. Pobranie łaty bezpośrednio do systemu, w którym chcę ją zastosować, za pomocą curl, jak wyjaśniono w https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e, zawsze działało dla mnie, z wyjątkiem przypadków, gdy wypróbowałem ją na Cygwin

Zaawansowany sposób radzenia sobie z nieudanymi łatkami: @PeterOCallaghan zasugerował skomentowanie suchej linii i ręczne radzenie sobie z plikami * .rej. W ten sposób łatkę można częściowo zastosować, a jeśli nie uda się usunąć plików SWF, można to zrobić ręcznie. Lub jeśli nie uda się zaktualizować plików, downloaderponieważ usunąłeś ten katalog, możesz to zignorować.

  1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh(lub podobna nazwa pliku) zmienią _apply_revert_patch dry-runwygląd #_apply_revert_patch dry-run

  2. uruchom łatkę, wydając ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

Spowoduje to załatanie twoich plików

  1. Komentarz _apply_revert_patchdo#_apply_revert_patch

  2. uruchom łatkę ponownie, aby dodać app/etc/app/etc/applied.patches.listpozycję

  3. grep dla wszystkich plików .rej z

    git status | grep *.rej

  4. ręcznie pracować w tych zmianach

Problemy po zastosowaniu poprawki

Formularz klucze

  • W wersjach Magento wcześniejszych niż 1.8 wprowadzono zmiany w frontend/base/defaultszablonach. Upewnij się, że ręcznie zastosujesz te same zmiany w kompozycji, jeśli zastąpi ona te pliki

    Mówiąc dokładniej, dodano klucz formularza dla działań frontendowych, takich jak:

    • Usuwanie elementu z listy życzeń
    • Usuwanie adresu klienta z widoku sklepu
    • Aktualizowanie wyceny w koszyku

    Zobacz tę odpowiedź @LukeRogers, jeśli napotkasz problemy z tymi działaniami.

Niestandardowy program do przesyłania

Unirgy_Rapidflow i inne rozszerzenia z niestandardowymi formularzami przesyłania już nie działają.

Zobacz odpowiedź @mpchadwick i komentarz @lloiacono

Naprawiłem go zastępując $this->getUploader()->getConfig()ze $this->getUploader()->getUploaderConfig()wUnirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

Aby dowiedzieć się, czy którekolwiek z Twoich rozszerzeń tego używa, możesz uruchomić następujące polecenie w wierszu polecenia:

grep -R 'getUploader()->getConfig();' app/code/community

Zgłoszone komunikaty o błędach

  • Błąd krytyczny PHP: Wywołanie niezdefiniowanej funkcji hash_equals ()

    dzieje się, jeśli jesteś na wersji PHP przed 5.6 i zastąpić code/core/Mage/core/functions.phpw code/local/Mage/core/functions.php(co może mieć miejsce w przypadku korzystania z rozszerzeń Fishpig). Zobacz tę odpowiedź : @ClaudiuCreanga


Problemy rozwiązane w v2 łatki

Jeśli wystąpi którykolwiek z tych problemów, prawdopodobnie używasz wersji 1 poprawki („v1” w nazwie pliku). Pobierz łatkę ponownie, aby uzyskać „v2”, która rozwiązuje te problemy:

  • Wystąpił problem ze zgodnością z SUPEE-3941 i downloader/lib/Mage/HTTP/Client/Curl.php

  • „Wyjątek” z komunikatem „Nieobsługiwany typ danych N” w /lib/Unserialize/Reader/ArrValue.php

  • Łatka dla EE 1.14.2.0 przypadkowo zawierała nowy plik test_oauth.php, który należy usunąć! Zobacz tę odpowiedź autor: @MatthiasZeis

Fabian Schmengler
źródło
Klucz formularza dodany podczas aktualizowania wyceny w koszyku nie jest czymś, co zostało dodane do SUPEE-8788 (przynajmniej od wersji 1.9.2.4)
Raphael w Digital Pianism
@RaphaelatDigitalPianism przynajmniej łatka 1.13.0.1 dodaje weryfikację klucza formularza do Mage_Checkout_CartController::updatePostAction, potencjalnie także innych wersji łatek.
Luke Rodgers
23

Jeśli dostaniesz

Call to undefined function hash_equals() error

nawet jeśli łata się powiodła, może to oznaczać, że skopiowałeś plik functions.php app/code/local/Mage/Core.

Trzeba tam również wstawić tę funkcję, ponieważ plik ten nadpisuje rdzeń.

Więc wstaw app/code/local/Mage/Core/functions.phpna końcu:

if (!function_exists('hash_equals')) {
    /**
     * Compares two strings using the same time whether they're equal or not.
     * A difference in length will leak
     *
     * @param string $known_string
     * @param string $user_string
     * @return boolean Returns true when the two strings are equal, false otherwise.
     */
    function hash_equals($known_string, $user_string)
    {
        $result = 0;

        if (!is_string($known_string)) {
            trigger_error("hash_equals(): Expected known_string to be a string", E_USER_WARNING);
            return false;
        }

        if (!is_string($user_string)) {
            trigger_error("hash_equals(): Expected user_string to be a string", E_USER_WARNING);
            return false;
        }

        if (strlen($known_string) != strlen($user_string)) {
            return false;
        }

        for ($i = 0; $i < strlen($known_string); $i++) {
            $result |= (ord($known_string[$i]) ^ ord($user_string[$i]));
        }

        return 0 === $result;
    }
}
Claudiu Creanga
źródło
1
Wiem, że Fishpig wymaga tego od ciebie. Więc jeśli masz to zainstalowane, będzie to dla ciebie problem.
mpchadwick
1
Uwaga: Byłem zdezorientowany i to MWI prosi o przesłanie funkcji.php, a nie Fishpig mwi-plugin.com/documentation/installation
mpchadwick
18

W PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.shpliku test_oauth.phpjest tworzony katalog główny Magento. Będziesz chciał usunąć ten (lub przynajmniej nie wdrożyć go w środowisku produkcyjnym), ponieważ może ujawnić pełną ścieżkę stosu wyjątków osobie dzwoniącej pod adresem URL https: //thedomain.tld/test_oauth.php .

Matthias Zeis
źródło
Niezły chwyt, Matthias! Byłoby to dość zła forma do wdrożenia 17 łat APPSEC i otwarcia innego wektora w tym samym czasie. Zgłosiłeś to już do Magento?
Bryan „BJ” Hoffpauir Jr.
Otworzyłem bilet na ten temat z pomocą Magento, jak jestem pewien, że inni w tym momencie. Nie słyszeliśmy o wersji łatki v2, ale powinni być świadomi problemu.
quasiobject
1
Pojawi się wersja v2, powinna być opublikowana wkrótce. Tak, zgłosiłem to, pisząc tutaj.
Matthias Zeis
1
Wygląda na to, że teraz jest to naprawione
Erfan
18

TO ZASTOSUJE DO WERSJI 1.7 MAGENTO


Jeśli korzystasz z wersji 1.7.0.2 SUPEE 8788 , awaria linii 372 nie powiedzie się, próbując zastosować zmiany do Curl.php:

patching file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client

Instrukcje mówią, że powinniśmy przywrócić SUPEE-1533 i zainstalować SUPEE-3941

PROBLEM: SUPEE-3941 jest dostępny tylko dla Magento CE 1.8-1.9. Możesz spróbować zastosować go w wersji 1.7, a będzie on obowiązywał. Myślętwórcy łatek Magento powinien albo wydać wersję 3 SUPEE-8788 dla osób korzystających z Magento poniżej 1.8 lub utworzyć dodatkową łatkę SUPEE-3941, która jest przeznaczona dla wersji poniżej 1.8.

Btw wersja 1 SUPEE-8788 nie miała Curl.phpbłędu w wersji 1.7.0.2 (przetestowałem go na wielu instalacjach)

Wskazówka: jeśli napotykasz na końcu błędy .swf, upewnij się, że skompresowałeś łatkę, załadowałeś ją na serwer i tam zdekompresowałeś. Błąd SWF zniknie.

AKTUALIZACJA:

Magento powiedział, że zasadniczo poprawne jest zainstalowanie łatki SUPEE-3941 w wersji Magento 1.7.0.2, aby uniknąć błędów podczas stosowania SUPEE-8788

Ikona
źródło
Byliśmy zrezygnował
datasn.io
@ kavoir.com również pojawia się ten sam błąd CURL.PHP podczas instalacji w wersji 1.7.0.2?
Ikona
1
Ten sam problem tutaj zainstaluj 8788 V2 w wersji 1.7.0.2, chociaż interesujące jest to, że ten sam błąd curl.php pojawia się na naszych nowszych stronach w wersji 1.9.2.1, które nie mają dostępnego SUPEE-3941. cofnięcie 1533 również nie pomaga temu problemowi
Jon Holland
@JonHolland Napisałem do zespołu magento ... Mam nadzieję, że odpowiedzą
Ikona
2
Otrzymałem odpowiedź od lidera społeczności Magento, w zasadzie dobrze jest zainstalować łatkę 3941 w wersji 1.7.0.2.
Ikona
15

Oryginalny DashboardController.php (1.7.0.2 - Nie zbuforowany, świeżo z Magento)

  if ($params = unserialize(base64_decode(urldecode($gaData)))) {

1533 Łata DashboardController.php zawiera następującą zmianę

 if ($newHash == $gaHash) {
            $params = json_decode(base64_decode(urldecode($gaData)), true);
            if ($params) {

Poprawka 8788 wprowadza następującą zmianę w DashboardController.php

 if (hash_equals($newHash, $gaHash)) {
            if ($params = unserialize(base64_decode(urldecode($gaData)))) {

Jak widać, 8788 ma zmodyfikowaną zmianę w porównaniu do 1533, NIE jestem pewien, czy to idealna modyfikacja pliku, jak sugeruje mpchadwick, poprzez ręczne zastąpienie zmiany 8788 1533 po zainstalowaniu 8788. Zasadniczo usunięcie zmiany 8788.

Jakieś sugestie?

Ikona
źródło
2
IMO Pożądanym rezultatem końcowym jest połączenie tych dwóch. Powinien to być json_decode, ale powinien używać raczej hash_equals niż ==. Zapobiega to atakowi czasowemu (co byłoby niezwykle trudne do wykorzystania).
Peter O'Callaghan
Zgadzam się z @Peter. Jeśli używasz Git, przywróć zatwierdzenie dla SUPEE-1533, zastosuj nową łatkę, zatwierdz, a następnie ponownie przywróć zatwierdzenie przywracające. Konflikt DashboardController.phppowinien zostać rozwiązany automatycznie.
Fabian Schmengler
1
Czy możesz podać fragment kodu DashboardController.php, który powinniśmy zastąpić po zainstalowaniu 8788? Nie jestem do końca pewien, co edytować, jak wspomniałem powyżej, łatane linie 1533 i 8788 wyglądają inaczej. Czy możesz podać, jak powinna wyglądać ręcznie zmodyfikowana wersja?
Ikona
Czy tak powinien wyglądać kod 8788 po ręcznej modyfikacji przy aktualizacji 1533? if (hash_equals ($ newHash, $ gaHash)) {if ($ params = json_decode (base64_decode (urldecode ($ gaData)))) {
Ikona
1
Uwaga dotycząca cofania zatwierdzeń dwa razy: możesz być w stanie użyć git revert -n 123456abi git cherry-pick -n 123456abtymczasowo cofnąć SUPEE-1533 bez tworzenia dodatkowych zatwierdzeń.
Matthias Zeis,
14

Połowa pokusiła się, aby oznaczyć ten post jako oparty głównie na opiniach lub bez wyraźnej odpowiedzi;)

Klucze formularzy zostały dodane do kilku kontrolerów, ich liczba zmienia się w zależności od wersji magento.

Jeśli wystąpią problemy

  • Usuwanie elementu z listy życzeń
  • Usuwanie adresu klienta z widoku sklepu
  • Aktualizowanie wyceny w koszyku

Konieczne będzie sprawdzenie .phtmlpliku motywów i upewnienie się, że POSTnadpisujesz parametr klucza formularza, aby przejął kontrolę w czynnościach kontrolera, takich jak:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

     public function updatePostAction()
     {
+        if (!$this->_validateFormKey()) {
+            $this->_redirect('*/*/');
+            return;
+        }
+

Problemy te potknęły wiele osób w poprzednich łatach, niestandardowe motywy interfejsu użytkownika z przesłoniętymi szablonami można łatwo pominąć przy stosowaniu poprawek.

Klucze formularza są często dodawane do .phtmlszablonu zawierającego formularz jako dodatkowy element inputpodobny

<input name="form_key" type="hidden" value="<?php echo $this->getFormKey() ?>" />
Luke Rodgers
źródło
Czy istnieje pełna lista formularzy, na które to wpływa? Więc mogę przetestować i naprawić je WSZYSTKO raz na zawsze. Nie chcę potajemnie głupich dysfunkcji, takich jak to, aby denerwować klientów lub obniżać współczynnik konwersji.
datasn.io
Jeśli SUPEE 8788 instaluje się doskonale w wersji 1.7 i wprowadza zmiany w (app / design / frontend / base / default / template .....). Ale pomimo zmiany listy życzeń frontonu strony, dodaj przyciski usuwania wszystko działa idealnie. Czy nadal musimy ręcznie łatać pliki motywów? Lub, skoro długa łata niczego nie psuje na interfejsie, który możemy pozostawić w obecnej postaci?
Ikona
11

Ten sam problem spotkałem w swf w 1.9.2.4.

Naprawiono lisa - wykonaj poniższe czynności.

Krok 1. Pobierz plik SSH poprawki 8788 do tego łącza: - https://magento.com/tech-resources/downloads/magento/

Krok 2. Po pobraniu poprawki zabezpieczeń 8788 plik SSH Proszę umieścić w jednym folderze i zrobić ten sam folder Plik zip.

Krok 3. Prześlij folder Zip do głównego folderu Magento i rozpakuj za pomocą SSH Putty.

Krok 4. Uruchom łatkę: - $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

* Uwaga: plik łatki zawiera całe pliki binarne w formacie tekstowym, dlatego po przesłaniu poprawki zabezpieczeń 8788 SSH bez pliku zip ten sam plik zostanie uszkodzony. *

Randhir Yadav
źródło
10

Po zastosowaniu SUPEE-8788 nie byłem już w stanie załadować profili „Importuj” za pomocą Unirgy_RapidFlow 2.0.0.18, otrzymując błąd 500 (nic w dziennikach Apache lub HTTPD).

Nadal jestem w trakcie debugowania i pracuję z Unirgy w celu rozwiązania problemu, ale wygląda na to, że przyczyną problemu jest blokada programu do przesyłania plików ( Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

Łatka wprowadziła kilka zmian do Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Contentelementu nadrzędnego.

Oprócz uRapidFlow, inne moduły innych firm, które pozwalają na przesyłanie plików, mogą ulec awarii w wyniku SUPEE-8788.

mpchadwick
źródło
znalazłeś już na to rozwiązanie? Naprawiłem go zastępując $ this-> getUploader () -> getConfig () z $ this-> getUploader () -> getUploaderConfig () w Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload
lloiacono
Dobrze do teraz. Wygląda na to, że Unirgy naprawił to w wersji 2.0.0.23. secure.unirgy.com/release-notes.php?m=1#RapidFlow Pracuję z klientem, aby kupić dodatkowe aktualizacje i nie byłem w stanie sprawdzić poprawności.
mpchadwick,
uruchom to na swoim docroot, aby dowiedzieć się, które inne pliki wymagają naprawy: grep -r 'getUploader () -> getConfig ()' ./
lloiacono 19.10.16
8

Podczas wykonywania skryptu poprawki dostałem następujący komunikat:

can't find file to patch at input line 4753
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
|index 6d0607e..5757be3 100644
|--- downloader/lib/Mage/HTTP/Client/Curl.php
|+++ downloader/lib/Mage/HTTP/Client/Curl.php

Myślę, że dzieje się tak, ponieważ zmieniłem nazwę folderu „downloader”, postępując zgodnie z zaleceniami z https://www.magereport.com .

Tymczasowo zmieniłem nazwę folderu na „downloader”, poprawnie zastosowałem łatkę, a następnie zmieniłem nazwę na swoją tajną nazwę.

TheTrueTDF
źródło
8

Łata w wersji 1.9.0.0 również zawiedzie (prawdopodobnie dotyczy to wersji 1.8.0.0 do wersji 1.9.0.1) z powodu SUPEE-3941. 3941 łatek downloader / lib / Mage / HTTP / Client / Curl.php i teraz 8788 nie działa.

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 378.
1 out of 1 hunk FAILED
checking file js/lib/uploader/flow.min.js

Obejście dla wersji 1.9.0.1 poniżej. Zmiany są zbyt dokładne, być może trzeba dostosować samą łatkę 8788.

edit: Edytuj łatkę, wyszukaj Curl.php i zamień

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         }

         $this->curlOption(CURLOPT_URL, $uri);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, FALSE);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');

         // force method to POST if secured
         if ($isAuthorizationRequired) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js 

z

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         $uriModified = $this->getSecureRequest($uri, $isAuthorizationRequired);
         $this->_ch = curl_init();
         $this->curlOption(CURLOPT_URL, $uriModified);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, false);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');
         $this->getCurlMethodSettings($method, $params, $isAuthorizationRequired);

         if(count($this->_headers)) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js
infabo
źródło
Dostosowałem pliki łatek, aby działały we wszystkich wersjach Magento po zainstalowaniu wszystkich poprzednich łat: magentohosting.pro/files/MageHost.pro_fixed_SUPEE-8788_v2.zip
Jeroen Vermeulen - MageHost
8

Oto co dostaję

Hunk #1 FAILED at 373.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client/Curl.php.rej
patching file js/lib/uploader/flow.min.js
patching file js/lib/uploader/fusty-flow-factory.js
patching file js/lib/uploader/fusty-flow.js
patching file js/mage/adminhtml/product.js
patching file js/mage/adminhtml/uploader/instance.js
patching file skin/adminhtml/default/default/boxes.css
patching file skin/adminhtml/default/default/media/flex.swf
patching file skin/adminhtml/default/default/media/uploader.swf
patching file skin/adminhtml/default/default/media/uploaderSingle.swf
patching file skin/adminhtml/default/default/xmlconnect/boxes.css
Haim
źródło
Uzyskanie dokładnie tego samego błędu w instalacji. Chciałbym wiedzieć, czy coś wymyśliłeś.
TunaMaxx
Nie, wciąż czekam, aż ktoś to
rozwiąże
2
Zobacz magento.stackexchange.com/a/73957/9276 . Jeśli plik Curl.php ma tę poprawkę, cofnij tę zmianę (przywróć linię do CURLOPT_SSL_CIPHER_LIST / 'TLSv1'), zastosuj łatkę i ponów zmianę.
Joe
Dzięki @Joe. Właśnie wróciłem tutaj, aby opublikować te same informacje. Pobiłeś mnie do tego! Właśnie to dostaję za pójście spać. :)
TunaMaxx
Miałem ten sam problem, to rozwiązało. Dzięki!
dafyddPrys
8

Wygląda na to, że Magento wyda zaktualizowaną wersję SUPEE 8788, aby naprawić kompatybilność SUPEE 1533. Nie jestem pewien, czy dobrym pomysłem jest teraz zastosować poprawki ręczne. Ręczne zmiany mogą zagrozić przyszłym aktualizacjom poprawek. Chciałbym usłyszeć twoje myśli.

Zostało to potwierdzone przez Magento Community Manager. W dniu 13 października, godzina piętnasta EST .. wszystkie łatki dla wersji poniżej 1.9 są usuwane z listy pobierania https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 Zobacz post: https://community.magento.com/t5 / Poprawki zabezpieczeń / SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error / mp / 50514 / highlight / false # M1805

Ikona
źródło
1
Jeśli zaktualizowana łata ma dokładnie ten sam wynik, co nasze poprawki ręczne i mam nadzieję, że tak jest, to nie widzę problemu. Zaktualizowana łatka nie będzie konieczna, a przyszłe łatki nie zobaczą różnicy.
Fabian Schmengler,
1
@fschmengler całkiem podobny do niekompatybilności PHP 5.5 dla SUPEE-7405 IMO. Łatka będzie odzwierciedlała poprawkę ręczną.
Raphael w Digital Pianism
1
@fschmengler Według mojej wiedzy magento wyda dokładnie tę samą łatkę z poprawkami. Sądzę, że najlepiej jest usunąć starą łatkę (samodzielnie zmodyfikowaną) i zainstalować nową (prawdopodobnie wydanie następnego dnia. Do jutra powinniśmy mieć aktualizację. Dziękujemy za pomoc!
Ikona
Nie wątpię w wartość tego wkładu, ale pozostając przy stylu pytań i odpowiedzi, ta odpowiedź nie wydaje mi się odpowiedzią, a raczej aktualizacją, którą @fschmengler mógłby dodać do swojego pierwotnego pytania (lub możesz dodać go do Odpowiedź Wiki Wiki).
7ochem
8

Otrzymujemy raporty o następujących nowych problemach, których nie widzę w innych postach:

  • W niektórych przypadkach wyjątek w nowych wersjach - wywołanie metody addCrumbs () (w przypadku, gdy getStoreConfig (web / default / show_cms_breadcrumbs) jest niezdefiniowany). Nie powinno to wpływać na łatę, tylko wydanie 1.9.3 / 1.14.3

„Wyjątek” z komunikatem „Nieobsługiwany typ danych N” w /lib/Unserialize/Reader/ArrValue.php w 1.9.1.0 i być może wcześniejszych wersjach po zastosowaniu poprawki. rozwiązany w wersji łatki 2.

Obecnie nie ma znanych łatwych obejść tych problemów. Pracujemy nad ich rozwiązaniem w nowej wersji łatki.

Piotr Kamiński
źródło
Możliwa poprawka dla nieobsługiwanego błędu typu danych N gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
Raphael at Digital Pianism
Masz pomysł, jak przezwyciężyć błąd Curl.php podczas instalacji SUPEE 8788 w wersjach 1.6 i 1.7?
Ikona
8

Program do przesyłania zepsuje się, gdy prześlesz ten sam plik dla próbek i linków w tym samym czasie dla produktów do pobrania. Pamiętaj, że dzieje się tak tylko wtedy, gdy używasz tego samego pliku w obu obszarach. (Kiedyś działał poprawnie przed łatką.)

Aby odtworzyć, edytuj produkt do pobrania i kliknij kartę Informacje do pobrania :

  1. Otwórz wiersz Próbki akordeonu i wyszukaj plik przykładowy.
  2. W wierszu Łącza akordeonu wyszukaj link do pobrania
  3. Kliknij opcję Prześlij pliki z sekcji Łącza.

Program przesyłający przesyła przykładowy plik zamiast pliku łącza do pobrania, a plik, który przeglądałeś w sekcji łącza do pobierania, znika.

Udało mi się to odtworzyć na waniliowej, poprawionej instalacji 1.7.0.2 CE.

Laura
źródło
Okazuje się, że jest to zachowanie podstawowej biblioteki JS używanej do przesyłania: github.com/flowjs/flow.js/issues/76
Laura,
6

Tak, napotkałem inny problem podczas logowania, zawsze zwróci to:

Znalazłem to dlatego, że w klasie Enterprise_Pci_Model_Observer linii 165,

Zamiast:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPassword())) {

To naprawi:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPasswordHash())) {

Ponieważ nie lubię zmieniać rdzenia (nawet przejść na lokalny), najlepiej, jeśli Magento to naprawi lub wyjaśni. W tej chwili moje tworzy nowe rozszerzenia, aby to rozszerzyć i stworzyć funkcję getPassword () (ponieważ chcę się upewnić, że wszyscy deweloperzy korzystają z trybu programisty).

dimasdwika
źródło
2
Po zastosowaniu V2 łatki mam ten sam problem z łataniem EE1.12. Wygląda na to, że ten plik zmienił się w pewnym momencie między 1.12 a 1.14, ale nie jako część łatek
Chris,
1
Podnieśli to z Magento i dostarczyli kolejną łatkę, aby rozwiązać ten problem. Zmiana jest identyczna jak powyżej.
Chris
6

Edycja pliku łatki

Jeśli ktoś musi edytować plik łatki, nie powinieneś tego robić w edytorze, ponieważ spowoduje to uszkodzenie plików binarnych zawartych w łatce.

Jeśli masz pod ręką linię poleceń, tj. linux / * unix spróbuj użyć sednarzędzia do usunięcia określonych linii.

Rekwizyty dla @fooman za wskazówkę. Zobacz jego pierwotną treść

Przykład sed -ie '101,111d' PATCH_SUPEE-8788_CE_1.7.0.2_v1-2016-10-11-06-36-18.sh

Spowoduje to usunięcie wierszy od 101 do 111 włącznie.

Problemy z przesyłaniem formularzy.

Jeśli widzisz powyższy problem, możesz również:

<?= $this->getBlockHtml('formkey'); ?>

Więcej informacji można znaleźć w tym poście Co to jest getBlockHtml ('formkey')?

Siergiej Filippow
źródło
4
Uważaj, <?=ponieważ nie jest włączony w każdej konfiguracji php
Raphael w Digital Pianism
@RaphaelatDigitalPianism masz rację. Chociaż <?=jest domyślnie włączony w większości konfiguracji php.ini, niektóre hosty decydują się go wyłączyć.
Siergiej Filippow,
5

CE 1.6.2.0 i SUPEE-3941

Aby zastosować poprawkę bezpieczeństwa SUPEE-8788 (wersja 2), ( http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new ) zaleca się najpierw zastosować SUPEE-3941 .

Jednak na stronie pobierania łatki nie ma poprawki SUPEE-3941 dla CE 1.6.2.0. Łatka jest dostępna tylko dla CE 1.8 i 1.9.

Jak wspomniano w tym wątku, wydaje się, że można zastosować dostępną łatkę SUPEE-3941 (dla CE 1.8 i 1.9) na CE 1.7.

Czy można również zastosować SUPEE-3941 (dla CE 1.8 i 1.9) w CE 1.6.2.0? Próbowałem zastosować go w CE 1.6.2.0 i otrzymałem następujący błąd:

Checking if patch can be applied/reverted successfully...
-e ERROR: Patch can't be applied/reverted successfully.

checking file downloader/Maged/Model/Connect.php
Hunk #1 succeeded at 489 (offset 3 lines).
checking file downloader/lib/Mage/Connect/Backup.php
checking file downloader/lib/Mage/Connect/Command.php
Hunk #1 FAILED at 64.
Hunk #2 succeeded at 205 with fuzz 2 (offset -44 lines).
Hunk #3 succeeded at 382 (offset -53 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Command/Install.php
Hunk #1 FAILED at 90.
Hunk #2 succeeded at 333 with fuzz 1 (offset 17 lines).
Hunk #3 succeeded at 363 (offset 17 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Packager.php
Hunk #4 FAILED at 268.
Hunk #5 FAILED at 290.
Hunk #6 succeeded at 369 with fuzz 2.
Hunk #7 FAILED at 377.
Hunk #9 FAILED at 428.
4 out of 10 hunks FAILED
checking file downloader/lib/Mage/Connect/Rest.php
Hunk #1 succeeded at 71 with fuzz 2 (offset -11 lines).
checking file downloader/lib/Mage/Connect/Singleconfig.php
Hunk #1 succeeded at 100 (offset -36 lines).
checking file downloader/lib/Mage/Connect/Validator.php
Hunk #1 succeeded at 418 (offset -41 lines).
Hunk #2 succeeded at 431 (offset -41 lines).
checking file downloader/lib/Mage/HTTP/Client/Curl.php
checking file downloader/template/settings.phtml
Mukesh Chapagain
źródło
5

Trochę późno, ale znaleźliśmy problem w łatce SUPEE-8788 V2, który przynajmniej dotyczy plików łatek dla Magento 1.7.0.2 i 1.7.0.1. Prawdopodobnie dotyczy to również wszystkich wcześniejszych wersji, dla których istnieje wersja łatki. Nie dotyczy to wersji Magento od 1.8, ponieważ łatka nie zmienia szablonów dla nich.

Szczegółowo

W poprawce brakuje klucza formularza dla pliku app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Bez tego logowanie nie działa przy kasie na stronie (po prostu nie działa bez błędu).

Naprawić

Klucz form należy wstawić jak w poniższej łatce:

diff --git a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
index 9d15a577b..18483a3c5 100644
--- a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
+++ b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
@@ -71,6 +71,7 @@
         <h3><?php echo $this->__('Login') ?></h3>
         <?php echo $this->getMessagesBlock()->getGroupedHtml() ?>
         <form id="login-form" action="<?php echo $this->getPostAction() ?>" method="post">
+        <?php echo $this->getBlockHtml('formkey'); ?>
         <fieldset>
             <h4><?php echo $this->__('Already registered?') ?></h4>
             <p><?php echo $this->__('Please log in below:') ?></p>
fheyer
źródło
4

W przypadku łatanej witryny 1533 po prostu zamień poniżej linii z PATCH_SUPEE-8788 *****. Sh:

diff --git app/code/core/Mage/Adminhtml/controllers/DashboardController.php app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index 09ffc4c..367bf8e 100644
--- app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,7 +91,7 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
+            if (hash_equals($newHash, $gaHash)) {
                 if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params) 

przez:

diff --git a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index ab2d654..367bf8e 100644
--- a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,9 +91,8 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
-                $params = json_decode(base64_decode(urldecode($gaData)), true);
-                if ($params) {
+            if (hash_equals($newHash, $gaHash)) {
+                if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params)
                             ->setConfig(array('timeout' => 5))
diff --git a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
index da1b14a..b6d72c0 100644
--- a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
+++ b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
@@ -444,7 +444,7 @@ class Mage_Adminhtml_Block_Dashboard_Graph extends Mage_Adminhtml_Block_Dashboar
             }
             return self::API_URL . '?' . implode('&', $p);
         } else {
-            $gaData = urlencode(base64_encode(json_encode($params)));
+            $gaData = urlencode(base64_encode(serialize($params)));
             $gaHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
             $params = array('ga' => $gaData, 'h' => $gaHash);
             return $this->getUrl('*/*/tunnel', array('_query' => $params));

Zasadniczo po prostu cofnął 1533 i opuścił 8788.

William Zhao
źródło
Jak rozumiem, 8788 zastępuje zmiany w DashboardController.php, a oryginalne 1533 zmiany zostaną wyeliminowane?
Ikona
2
Tak, celem 1533 zastąpienia serialize () przez json_encode () było zmniejszenie szansy na atak ($ ​​newHash == $ gaHash). Podczas gdy 8788 dodaje hash_equals () w tym samym celu
William Zhao,
Świetnie, myślałem o zrobieniu nieco innej drogi, na mojej stronie testowej załadowałem czysty DashboardController.php (zapasowy plik magento) i zainstalowałem SUPEE 8788. Czytałem jednak na tym forum i dżentelmena wspomnianego o ręcznym przywróceniu supee 1533 zmian w Supee 8988 zmodyfikowany plik. Co myślisz o mojej metodzie?
Ikona
Ikona, spójrz na moją różnicę powyżej, na swój sposób musisz cofnąć wiersz zaktualizowany przez SUPEE 1533 w 'app / code / core / Mage / Adminhtml / Block / Dashboard / Graph.php', jeśli już masz SUPEE 1533 załatane. W przeciwnym razie Graph.php uruchomi parametry formatu json i nie będzie można go zdekodować przez unserialize ()
William Zhao,
4

Przechwytywanie Authorize.net jest przerywane po zastosowaniu łatki. Autoryzacja działa dobrze, ale podczas przechwytywania płatności do faktury pojawia się komunikat „Błąd bramki: wymagany jest numer karty kredytowej” . Plik dziennika płatności pokazuje teraz x_typewartość parametru param auth_capturepass, ale przed łatką przepuszczał, prior_auth_captureco działało dobrze. Czy ktoś ma ten problem?

AKTUALIZACJA: Naprawiono ten problem - Authorize.net nie przechwytuje

Kalpesh
źródło
4

Poprawiłem kopię Magento 1.9.2.4 za pomocą SSH z SUPEE-8788 Poprawiłem inną kopię Magento 1.9.2.4 za pomocą ftp z SUPEE-8788 Poprawiłem kopię Magento 1.9.1.0 za pomocą SSH z SUPEE-8788 Mam użył świeżej kopii Magento 1.9.3.1

Na wszystkich tych stronach Magento z SUPEE-8788 mam ten sam problem (może błąd poprawki)

Używając produktów do pobrania i przechodząc do informacji do pobrania-> Próbki, gdy próbuję dodać nowy wiersz (jeden lub więcej), klikając „X”, nie jestem już w stanie usunąć wierszawprowadź opis zdjęcia tutaj

Nie jestem ekspertem od Magento, próbuję znaleźć rozwiązanie. Jeśli znajdę, opublikuję, jeśli ktoś z was ma jakieś rozwiązanie, będzie to dla mnie bardzo przydatne

AKTUALIZACJA : za pomocą Inspektora Chrome zobaczyłem ten błąd:wprowadź opis zdjęcia tutaj

******* ZNALAZŁEM ROZWIĄZANIE *******

Spędziłem 2 dni i mam nadzieję, że to może pomóc komuś innemu, to jest błąd w SUPEE-8788

Otwórz sample.phtml w środku app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable

Znajdź funkcję

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        element.down('div.flex').remove();
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

i zamień na

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        Element.select(element, 'div.flex').each(function(elm){
            elm.remove();
        });
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

To rozwiąże BŁĄD

Ivan
źródło
3

Zastosował PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-43 na testowej kopii witryny z wersją 1.9.2.1 i zepsuł się zamówienie. Po przywróceniu poprawki łatka działa normalnie.

Po złożeniu zamówienia zabiera Cię z powrotem do koszyka zamiast sukcesu w kasie. Pomyśl, że będę czekał na wersję .1, zanim spróbuję ponownie.

Adam Lavery
źródło
brzmi jak zgłoszony wyjątek podczas zapisywania zamówienia, czy sprawdziłeś dzienniki?
simonthesorcerer
Tak to wygląda ... Błąd krytyczny PHP: nie znaleziono klasy „Mage_Core_Helper_UnserializeArray” w ... / public_html / app / Mage.php w linii 547
Adam Lavery,
@AdamLavery Przejdź do Var / cache i usuń folder pamięci podręcznej. Ten błąd pojawia się, gdy przywracam pamięci podręczne z powrotem do oryginału. To sprawa z pamięcią podręczną.
Ikona
Nowa łatka ukaże się wkrótce. To ogromna aktualizacja łatki, której nie można oczekiwać od błędów ... Tak ... kciuki.
Ikona
1
Jest to prawdopodobnie spowodowane brakiem app/code/core/Mage/Core/Helper/UnserializeArray.phptego. Dodano go w SUPEE-6788, którego być może nie zainstalowałeś. Wygląda na to, że SUPEE-8788 ma nieudokumentowaną zależność od SUPEE-6788.
Tyler V.
3

Nowy e-mail we wczesnych godzinach od Magento informuje, że będą produkować nowe wersje łatek, aby rozwiązać problemy ze zgodnością SUPEE-1533 i SUPEE-3941. Więc może po prostu trzymaj trochę koni.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3 i SUPEE-8788 Enterprise Edition 1.14.3 i Community Edition 1.9.3 zapewniają ponad 120 ulepszeń jakości, a także obsługę PHP 5.6. Rozwiązują również krytyczne problemy bezpieczeństwa, w tym: ...

... Łatka SUPEE-8788 rozwiązuje te problemy bezpieczeństwa we wcześniejszych wersjach Magento. Niestety odkryliśmy, że poprawki SUPEE-8788 do wersji Community Edition 1.8 i wcześniejszych oraz Enterprise Edition 1.13 i wcześniejszych wersji zawodzą, jeśli sklep wcześniej zastosował poprawki bezpieczeństwa SUPEE-1533 lub SUPEE-3941. Pracujemy nad rozwiązaniem tego problemu i udostępnimy nowe łatki w ciągu jednego do trzech dni. Do tego czasu usuwamy te wersje poprawki SUPEE-8788 z dystrybucji ...

Obawiam się jednak, że moje aktywne wersje Magento mieszczą się w CE 1.9.3, które, jak mówią, działają, a nowe wersje będą wkrótce dostępne dla wersji 1.8 i niższych. Skontaktowałem się z nimi, więc poczekam i zobaczę, co powiedzą.

Jon Holland
źródło
Mam nadzieję, że nie jest to „odpowiedź”, ale przydatne informacje.
Jon Holland
Cześć Jon, możesz również edytować oryginalne pytanie @ fschmengler i dodać je na dole jako AKTUALIZACJĘ . Myślę, że nie przeszkadza mu to i zatwierdza tę edycję.
7ochem
Dobry pomysł, ale ktoś już coś dodał :)
Jon Holland
3

Nie jestem wielkim fanem łatania. Osobiście usuwam wszystkie pliki Magento z ich katalogów, a następnie przesyłam nową wersję (używając skryptu powłoki). Wszystkie pliki instalowane przez lata, takie jak moduły lub motywy, nadal tam są. Dla bazy danych dokonuję porównania między świeżo zainstalowanymi wersjami. Jednym ze sposobów jest tworzenie lub usuwanie kolumn / tabel do bazy danych, drugim sposobem jest ponowna instalacja Magento, po prostu zmiana nazwy pliku /app/etc/local.xml. Wolę pierwszy.

Jeśli nie zmienisz struktury bazy danych na wersję 1.9.3.0, wystąpią błędy lub nie będziesz mógł załadować obszaru administratora. Jeśli ktoś jest zainteresowany niektórymi porównaniami katalogów i baz danych Magento między Magento CE 1.9.2.4 i 1.9.3.0, wystarczy pobrać plik tutaj:

Porównanie Magento: wersje 1.9.2.4 - 1.9.3.0

Istnieją dwa pliki HTML z bardzo ładnymi efektami wizualnymi.

Zaktualizowałem dzisiaj 4 sklepy przy użyciu mojej metody zamiast łatania. Wszystkie działają bez żadnych problemów.

ADDISON74
źródło
To miłe, jeśli korzystasz z najnowszej wersji i jest nowa wersja łatki, tak jak było w przypadku 1.9.2.2, 1.9.2.3 i 1.9.2.4 - jednak dla tej łatki nie było nowej wersji 1.9.2.5 . Wersja 1.9.3.0 zawiera szereg dodatkowych zmian niezwiązanych z bezpieczeństwem.
Fabian Schmengler
Dzięki mojej metodzie mam dwa w jednym, aktualizacje zabezpieczeń i nowe funkcje. Jedynym problemem jest to, że musisz zrozumieć, co dzieje się w systemie plików i bazie danych między wydaniami. To nie jest wielka sprawa, kiedy wiesz, co robisz. I masz lepszą kontrolę. Robię tę metodę od wersji 1.7.
ADDISON74
3

Brak szczęścia w większości instalacji Magento CE (łącznie 6). Różne wersje: 1.9.1, 1.9.0.1, 1.8.1.

Pobrałem poprawną odpowiednią poprawkę 8788. Upewniłem się, że w razie potrzeby cofam 1533.

Otrzymuję następujące kluczowe godne uwagi wyniki, które są wątpliwe:

Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

...

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.

... sprawdzanie pliku app / code / core / Mage / Adminhtml / controllers / IndexController.php Przystojniak nr 1 udało się na 373 (przesunięcie -19 linii). ...

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.ph

To samo co powyżej dla: lib / Unserialize / Reader / Arr.php lib / Unserialize / Reader / ArrValue.php I mówi, że te kawałki są ignorowane.

Uwaga: W moim katalogu Unserialized / Reader nie ma nic. Całkowicie pusty. Uwaga: plik Curl.php znajduje się w katalogu downloadera. Nie zmieniono nazwy. Kończy się, ale nie widzę usuniętych plików SWF. Nie widzę łatki zastosowanej na liście Appl.patches.list

Nie ma sensu.

Bogaty Jessian
źródło
Ok .. wymyśliłem to wszystko. Zdecydowanie trzeba pracować przez WSZYSTKIE stare łatki, w kolejności. Miałem kilka starszych łatek, które nie zostały nałożone. Kiedy je ściągnąłem i założyłem na linię, wszystko zaczęło się pomyślnie łatać. Jednak zauważyłem, że za każdym razem, gdy pojawia się błąd przystawki w pliku dla KAŻDEJ łatki, musiałem wejść do łatki i znaleźć to, co próbowała zastąpić, i ręcznie to zrobić w mojej instalacji Magento. Następnie usuń te linie „różnicowe” z łatki i uruchom ponownie. Zasadniczo za każdym razem, gdy zobaczysz błąd przystojniaka, wejdź do łatki i zobacz, co próbuje z niej uzyskać +/-, a następnie zrób to sam.
Rich Yessian
3

Poprawiłem dzisiaj około 10 stron internetowych i każda witryna, na której nie powiodła się poprawka SUPEE-8788, miała błąd SUPEE-6788 .

Spowodowało to (przykład) następujący błąd:

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.php

Po zainstalowaniu SUPEE-6788 SUPEE-8788 został poprawnie załatany.

Rann
źródło
3

Jeśli dostajesz Hunk #1 failedo xxx Błąd, to właśnie zrobiłem

Mam Hunk #1 failed at 373. Błąd !! po linii

sprawdzanie downloadera plików / lib / Mage / HTTP / Client / Curl.php

Więc sprawdziłem Curl.phpplik i stwierdziłem, że wcześniej go zmodyfikowałem (skomentowałem jedną linię). Przywróciłem oryginalny plik i ponownie uruchomiłem łatkę. Następnie łatka zakończyła się powodzeniem. ;).

Potem sprawdziłem:

/app/etc/applied.patches.list i wszystko wydaje się dobre

Shan
źródło