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

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?

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

• Magento 1.9.2.0 SUPEE-8788 v2 Hunk # 1 NIE POWIODŁO się na 91 po cofnięciu SUPEE-1533
• Nie można zastosować poprawki w modelu PayPal Express: Magento 1.9.2.2 SUPEE-8788 v2 Hunk # 1 FAILED
• Przypadek niezwiązany z łatką Wiadomości e-mail przestały być wysyłane 1.8: https://magento.stackexchange.com/q/141799/2380 i problem z łatką bezpieczeństwa 8788 V2
• Wstecznie niezgodna zmiana podczas wywoływania getConfig()metody z bloku programu przesyłającego: Problem w panelu administracyjnym po instalacji poprawki SUPEE 8788

Znane problemy z SUPEE-8788 v1

• Aktualizacja: v2 poprawki rozwiązuje ten problem (patrz wyżej)Konflikt między SUPEE-1533 i SUPEE-8788 , możliwe (hacky) obejście tutaj . Mniej hacky rozwiązanie tutaj
• Aktualizacja: v2 poprawki rozwiązuje ten problem Unsupported data type Nbłąd w wersji /lib/Unserialize/Reader/ArrValue.php1.9.1.0 i prawdopodobnie we wcześniejszych wersjach po zastosowaniu poprawki. napraw tutaj: https://gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
• Aktualizacja: v2 poprawki rozwiązuje ten problem Możliwy konflikt z SUPEE-3941: https://magento.stackexchange.com/a/140696/2380
• Problem z OS X:Illegal Byte Sequence : SUPEE-8788 na OSX - nielegalne sekwencja bajtów
• Zniekształcona łatka (prawdopodobnie bue do sekwencji binarnej w łatce ) : zniekształcona łatka Magento 1.9.2.4 SUPEE-8788 w linii 5790
• Dołączenie test_oauth.phppliku z łatką EE , nie wypychaj tego pliku do prod
• Możliwy problem z logowaniem w EE związany zEnterprise_Pci : https://magento.stackexchange.com/a/140577/2380
• Problem, jeśli edytujesz plik łaty, ponieważ zawiera on pliki binarne w postaci enkapsulowanej , skorzystaj z tej metody, jeśli chcesz edytować: https://magento.stackexchange.com/a/140575/2380
• W przypadku, gdy użytkownik posiada app/code/localwersję Mage/Core/functions.phpbędziesz mieć problemu z nowej hash_equalsfunkcji : https://magento.stackexchange.com/a/140664/2380
• Warto wiedzieć, że wprowadzono pewne zmiany szablonów dotyczące form_key dla Magento przed 1.8
• Możliwy problem z 1.5.1.0 z downloader/Maged/View.php: Awaria poprawki bezpieczeństwa SUPEE-8788 w downloaderze / Maged / View.php (M1 v1.5.1.0)
• Incase usunął / zmienił nazwę downloaderfolderu: https://magento.stackexchange.com/a/140631/2380

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

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

3. Uruchom łatkę

Pracował dla mnie

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

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

3. Komentarz _apply_revert_patchdo#_apply_revert_patch

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

5. grep dla wszystkich plików .rej z

   git status | grep *.rej

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

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;
    }
}

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 .

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

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?

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() ?>" />

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

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.

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

Ł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

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

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

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.

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.

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

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')?

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

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>

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.

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

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ąć wiersza

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:

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

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.

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

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.

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.

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.

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