Nowa aktualizacja zabezpieczeń Magento 1, rozwiązująca 16 problemów APPSEC: https://magento.com/security/patches/supee-9767

Siedem luk w zabezpieczeniach ma ocenę 8,0 lub wyższą pod kątem ważności CVSSv3 i są one wykorzystywane na wolności, więc jest to krytyczna łatka. Witryny mogą stosować SUPEE-9767 lub aktualizację do nowej wersji CE 1.9.3.3 / EE 1.14.3.3.

Jakie są typowe problemy lub pułapki, na które należy zwrócić uwagę przy stosowaniu SUPEE-9767?

AKTUALIZACJA 2017-07-12:

Magento wydało SUPEE-9767 V2 i CE 1.9.3.4, aby rozwiązać wiele problemów z pierwszej łatki. Jeśli zastosowałeś V1, powinieneś cofnąć, a następnie zastosować V2. Jeśli jeszcze nie załatałeś, po prostu zastosuj V2, a większość poruszonych tutaj problemów nie będzie miała znaczenia.

Oto mój przegląd łatki po wkopaniu w nią

OSZCZĘDZANIE CZASU : Experius zapewnia pomocnika łatek, który pomaga znaleźć pliki w niestandardowych motywach, niestandardowych modułach lub lokalnych nadpisywaniach, które również mogą wymagać łatania ręcznego , można go znaleźć tutaj: https://github.com/experius/Magento- 1-Experius-Patch-Helper # magento

Klucze formularza zamówienia

Jak powiedziano w drugim poście, ta łatka dodaje klucze formularzy do następujących formularzy:

Formularz koszyka wysyłkowego:

app/design/frontend/<package>/<theme>/template/checkout/cart/shipping.phtml

Formularz płatności fakturowania wielostanowiskowego:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/billing.phtml

Formularz zamówienia wysyłki Multishipping:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/shipping.phtml

Formularz płatności adresów multipippingowych:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/addresses.phtml

Formularz płatności faktury:

app/design/frontend/<package>/<theme>/template/checkout/onepage/billing.phtml

Formularz zamówienia wysyłki:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping.phtml

Formularz płatności:

app/design/frontend/<package>/<theme>/template/checkout/onepage/payment.phtml

Formularz zamówienia metody wysyłki:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping_method.phtml

Formularz trwałego rozliczenia:

app/design/frontend/<package>/<theme>/template/persistent/checkout/onepage/billing.phtml

Ponadto zaktualizowano następujące pliki JS, aby były zgodne z tą zmianą:

• js/varien/payment.js
• skin/frontend/base/default/js/opcheckout.js

Co robić:

Jeśli korzystasz z niestandardowych wersji tych szablonów, musisz je zaktualizować, dodając do nich następujący kod:

<?php echo $this->getBlockHtml('formkey') ?>

Jeśli korzystasz z zewnętrznego modułu do kasy, musisz się z nimi skontaktować, aby mogli dostarczyć zaktualizowaną wersję swojego modułu.

Również jeśli masz niestandardowe wersje wcześniej wymienionych plików JS, musisz je również zaktualizować.

OSZCZĘDZAJ SWÓJ CZAS :

Fabian Schmengler napisał fajny mały skrypt, aby zaktualizować wszystkie te rzeczy dla Ciebie, możesz go znaleźć tutaj:

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

WAŻNA UWAGA : sprawdzanie poprawności klucza formularza formularza można zmienić w backendie za pomocą nowego pola konfiguracji w obszarze System> Konfiguracja> Administrator> Bezpieczeństwo> Włącz sprawdzanie klucza formularza przy kasie . TO NIE JEST WŁĄCZONE DOMYŚLNIE, więc musisz włączyć tę funkcję bezpieczeństwa !!! Pamiętaj, że otrzymasz powiadomienie w backend, jeśli nie jest włączone.

Oddzwanianie do przesyłania obrazu

Kontroler galerii obrazów został zaktualizowany, aby dodać wywołanie zwrotne sprawdzania poprawności.

Co robić

Jeśli używasz niestandardowego modułu, który przesyła obraz z kodem, który wygląda następująco:

        $uploader = new Mage_Core_Model_File_Uploader('image');
        $uploader->setAllowedExtensions(array('jpg','jpeg','gif','png'));
        $uploader->addValidateCallback('catalog_product_image',
            Mage::helper('catalog/image'), 'validateUploadFile');
        $uploader->setAllowRenameFiles(true);
        $uploader->setFilesDispersion(true);

Zdecydowanie sugeruję zaktualizowanie tego kodu poprzez dodanie następującego fragmentu po nim:

        $uploader->addValidateCallback(
            Mage_Core_Model_File_Validator_Image::NAME,
            Mage::getModel('core/file_validator_image'),
            'validate'
        );

Symlinks

Ta poprawka usuwa pole konfiguracji systemu, które pozwala na dopuszczenie dowiązań symbolicznych szablonu w wewnętrznej bazie danych. Kiedyś było w System> Konfiguracja> Deweloper> Szablon> Zezwalaj na dowiązania symboliczne . Teraz cała sekcja szablonów zniknęła.

Ponadto, to pole jest teraz domyślnie wyłączone przez app/etc/config.xml

Zabawne jest to, że otrzymasz powiadomienie w backend, jeśli masz włączone pole konfiguracji przed łatką, ale nie będziesz mógł go wyłączyć, gdy pole zniknie.

Jedynym sposobem na to jest uruchomienie następującego zapytania SQL

UPDATE core_config_data SET value = 0 WHERE path = "dev/template/allow_symlink";

Wyjaśnienie

Najpierw zdecydowanie zalecamy sprawdzenie tych dwóch postów, które pomogą ci zrozumieć cel tej modyfikacji Symlink:

• Od Peter O'Collaghan: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/
• Od Maxa Chadwicka: https://maxchadwick.xyz/blog/what-allow-symlinks-actally-does

Ta modyfikacja naprawdę polega na wywoływaniu treści do przesłania (takich jak obrazy) za pomocą dyrektyw szablonów.

Problem związany z dowiązaniami symbolicznymi można wykorzystać tylko w przypadku dostępu administratora, a Magento dodał także trochę więcej ochrony przed przesyłaniem obrazów.

Pamiętaj, że oprócz samego ustawienia są to niektóre zabezpieczenia przed znanym sposobem wykorzystania.

Co robić : jeśli tak jak ja, używasz modmana lub kompozytora z szablonowymi dowiązaniami symbolicznymi, napotkasz pewne problemy. Wciąż próbuję dowiedzieć się, co jest najlepsze do zrobienia, oprócz zajmowania się zapytaniami SQL.

Główny post na ten temat: SUPEE-9767, modman i dowiązania symboliczne

Lista możliwych problemów

Wersja 2 została wydana od czasu tego oryginalnego postu. Nie zapomnij zaktualizować

Robaki

Słowo „potwierdzone” jest używane w przypadku potwierdzonych błędów. Jeśli go nie ma, oznacza to, że może to być błąd, ale nie został jeszcze potwierdzony.

• Rejestracja klienta kończy się niepowodzeniem przy kasie POTWIERDZONY I NAPRAWIONY W V2
• POTWIERDZENIE błędu PHP7 i EE
• Błąd z EE, FPC i wyjątkami projektowymi POTWIERDZONY
• Dodaj do koszyka i błąd pliku cookie w EE POTWIERDZONY
• Przerwanie multishippingu po łatce POTWIERDZONE
• Brakująca poprawka whead-simple.phtml POTWIERDZONYM I NAPRAWIONYM W V2
• Ostrzeżenie Adlink Symlink nie jest wyświetlane w wersji 1.9.2 POTWIERDZONE I NAPRAWIONE W wersji 2
• Znak wodny dostaje czarne tło, gdy przezroczysty POTWIERDZONY I NAPRAWIONY W V2
• Nie można zaktualizować za pośrednictwem Magento Connect
• Nieskończona pętla przekierowań w wersji 1.6.0.0

Problemy z przystojniakiem

Pamiętaj, że wszystkie te problemy mogą wynikać z faktu, że zmodyfikowałeś oryginalny plik, aby dokładnie sprawdzić, czy tak nie jest:

• Utwórz kopię zapasową pliku, w którym pojawia się błąd „Nieudany przystojniak”
• Pobierz oryginalny plik ze swojej wersji Magento
• Porównaj oba pliki

Jeśli pliki są różne, musisz zastosować poprawkę do oryginalnego pliku, a następnie ponownie zastosować niestandardowe zmiany w czysty sposób, na przykład:

• szablon niestandardowy w niestandardowym folderze motywów
• local.xml
• aplikacja / kod / plik lokalny

Jeśli pliki nie różnią się, oznacza to, że jest to problem z pozwoleniem lub „błąd” w łatce.

• łatanie pliku app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED at 36.
• łatanie pliku app / design / frontend / enterprise / default / template / permanentent / checkout / onepage / billing.phtml Przystojniak nr 1 NIEPOWODOWANY w 225.
• łatanie aplikacji pliku / code / core / Enterprise / PageCache / Model / Observer.php Hunk # 6 FAILED at 1093.
• łatanie pliku app / code / core / Mage / Core / etc / system.xml Hunk # 3 FAILED at 1355.
• łatanie pliku app / code / core / Mage / Sales / Model / Quote / Item.php Hunk # 1 FAILED at 500.
• Hunk zawiódł w wersji 1.8.0.0

Problem 1: form_key jest nieprawidłowy przy kasie na stronie

Magento dodaje form_keyco najwyżej formularze.

jeśli tak using default onepage and using custom theme, zaczniesz otrzymywać ** form_keyproblem przy kasie każdego kroku **;

powinieneś dodać klucz formularza na <?php echo $this->getBlockHtml('formkey') ?>

do formowania każdego pliku kroku kasy, jeśli poniższe pliki wychodzą,

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/billing.phtml
• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/payment.phtml

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping.phtml

• app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping_method.phtml

jeśli pliki szablonów wywołują z motywu podstawowego , nie stwarza to problemu. Ponieważ łatka automatycznie zaktualizuje te pliki.

Uwaga: <?php echo $this->getBlockHtml('formkey') ?>powinien zawsze znajdować się wewnątrz znacznika formularza

 <form action="" .....>
     <fieldset>
      .......
       <?php echo $this->getBlockHtml('formkey') ?>
     </fieldset>
 </form>

** Jeśli korzystasz z kasy z wysyłką wielokrotną Magento, musisz to zrobić o

poniżej plików:

Problem 2: problem z form_key do formularza szacowania wysyłki na stronie koszyka:

Dodaj form_key przy szacunkowych kosztach wysyłki na stronie koszyka

Następnie należy dodać klucz formularza <?php echo $this->getBlockHtml('formkey') ?>

w app/design/frontend/{Your_Package}/{YOUR_THEME]/template/checkout/cart/shipping.phtml

Problem 3: Błąd Magento przy kasie na stronie opcheckout.js

Jeśli używasz domyślnej kasy na stronie i masz opcheckout.js to, sprawdź

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {jest dostępny na opcheckout.js

Jeśli nie, to wyjdź

if (elementy [i] .name == 'payment [method]') {

z

if (elementy [i] .name == 'payment [metoda]' || elementy [i] .name == 'form_key') {

W przypadku wydania 1, problemu 2, problemu 3 Problem można łatwo rozwiązać za pomocą skryptu @FabianSchmengler w skrypcie add-checkout-form-key.sh . Naprawi to problem z twoimi otwartymi plikami motywów

Problem 4: Niepoprawny klucz formularza po zalogowaniu klienta podczas przepisywania Mage_Customer_Model_Session

Jeśli Mage_Customer_Model_Sessionklasa przepisała lub zadzwoniła z

app/code/local/Mage/Customer/Model/Session.phpwtedy może pojawić się problem z form_key, kiedy ustawiamy klienta na sesję za pomocą setCustomerAsLoggedIn()/ lub po ustawieniu klienta na sesji.

W takim przypadku musisz zostać dodany

Mage :: getSingleton ('core / session') -> renewFormKey ();

w setCustomerAsLoggedIn () przed wywołaniem

Mage::dispatchEvent('customer_login', array('customer'=>$customer));

  public function setCustomerAsLoggedIn($customer)
    {
        $this->setCustomer($customer);
        $this->renewSession();
        // add this  for patch -9767
        Mage::getSingleton('core/session')->renewFormKey();
       // end this for patch 9767
        Mage::dispatchEvent('customer_login', array('customer'=>$customer));
        return $this;
    }

Problem 5: Problem z formularzem po wylogowaniu

Po wylogowaniu klienta z sesji może wystąpić problem z sesją, jeśli Mage_Customer_Model_Sessionklasa przepisze lub zadzwoniła z

app/code/local/Mage/Customer/Model/Session.php

W tych samych potrzebach w tym przypadku:

   protected function _logout()
    {
        $this->setId(null);
        $this->setCustomerGroupId(Mage_Customer_Model_Group::NOT_LOGGED_IN_ID);
        $this->getCookie()->delete($this->getSessionName());
// add this  for patch -9767
Mage::getSingleton('core/session')->renewFormKey();
        return $this;
    }

Zalecenie:

Zalecenie 1: Aby rozwiązać problem supee-9767 , możesz użyć poprawki https://github.com/experius/Magento-1-Experius-Patch-Helper

To na razie jedno najlepsze rozwiązanie.

Uwaga : przed zrobieniem tego zdecydowanie zaleca się wykonanie kopii zapasowej plików i bazy danych lub pełnej kopii zapasowej systemu.

Zalecenie 2: Użyj funkcji łaty w swoim ONESTEP CHECKOUT

Wiemy, że łatka supee-9767 dla celów bezpieczeństwa, jeśli używasz ONESTEP CHECKOUT, powinieneś dodać sprawdzanie poprawności form_key w celu ZAPISZ działanie twojego kontrolera transakcji onestep .

Przypuśćmy, że w celu zapisania szczegółów metody wysyłki, Twój pierwszy krok przy kasie ma opcję saveShippingmethod (). Następnie dodaj

if ($this->isFormkeyValidationOnCheckoutEnabled() && !$this->_validateFormKey()) {
           return;
      }

Również na Twoim formularzu phtml musisz dodać klucz formularza <?php echo $this->getBlockHtml('formkey') ?> na swoim pierwszym etapie realizacji transakcji

Niektóre powiązane linki

https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/

Na podstawie mojego pierwszego przejścia podczas przeglądu pliku poprawki ...

• Dodano nowe ustawienie admin/security/validate_formkey_checkout. Po włączeniu formularze płatności są sprawdzane pod kątem obecności klucza formularza. Jeśli pliki szablonów zostaną nadpisane w kompozycji, należy je tam zaktualizować. To ustawienie wydaje się domyślnie wyłączone
• Wydaje się, że dowiązania symboliczne są domyślnie niedozwolone (w app/etc/config.xml). Ponadto wydaje się, że możliwość ich zezwolenia została usunięta z konfiguracji administratora. Jeśli jednak Twoja witryna wcześniej wyraźnie włączała dowiązania symboliczne, ustawienie zostanie zapisane w bazie danych, zastępując tę ​​zmianę.
• Podczas stosowania tej poprawki musisz wyczyścić pamięć podręczną ORAZ pamięć podręczną całej strony. Wyjątki projektowe są zapisywane w formacie niezgodnym z dekodowaniem. Zobaczysz błąd taki jak „Dekodowanie nie powiodło się: błąd składni”, jeśli nie opróżnisz pamięci podręcznej strony.

Poniżej base/defaultpliku, którego dotyczy ta poprawka, jeśli te pliki były w Twoim motywie, wprowadź odpowiednie zmiany

app/design/frontend/base/default/template/checkout/cart/shipping.phtml

app/design/frontend/base/default/template/checkout/multishipping/billing.phtml

app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/billing.phtml

app/design/frontend/base/default/template/checkout/onepage/payment.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml

app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml

we wszystkich powyższych phtmlplikach poniżej formularza dodawana jest linia klucza, więc dodaj tę linię do odpowiedniego pliku phtml.

 <?php echo $this->getBlockHtml('formkey') ?>

Dla powyższego problemu @fabian utworzył skrypt, który doda klucz formy nawet w pliku motywu

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

po zastosowaniu poprawki bezpieczeństwa, jeśli pojawi się błąd klucza formularza, możesz zastosować tę poprawkę, ponieważ zastosowanie tej poprawki jest takie samo jak łatka bezpieczeństwa

  sh filename.sh

i jedna base/defaultzmiana w Jspliku

  skin/frontend/base/default/js/opcheckout.js

więc jeśli ten jsplik ładuje się z motywu, wykonaj poniższe czynności

usunąć linię wydmuchu

 if (elements[i].name=='payment[method]') {

i dodaj poniżej linii zamiast powyżej

 if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

EDYTOWAĆ

A jeśli używasz dowolnego rozszerzenia kasy, które przesłania poniższe pliki, dodaj linię klucza formularza do pliku phtml rozszerzenia kasy.

EDIT2 - problemy

1) Błąd podczas saveBillingAction () lub uzyskanie klucza formularza null lub problem z kluczem formularza: Patch 9767 uzyskiwanie nieprawidłowego klucza formularza

2) Hunk # 1 FAILED at 225. 1 z 1 hunk FAILED - zapisywanie odrzuceń do pliku app / design / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml : SUPEE-9767 - Hunk # 1 FAILED at 225. 1 z 1 przystojniaków FAILED

3) zapisywanie odrzuceń w pliku app / code / core / Enterprise / PageCache / Model / Observer.php.rej: SUPEE-9767 BŁĄD: Nie można pomyślnie zastosować / przywrócić poprawki

4) SUPEE-9767, modman i dowiązania symboliczne: SUPEE-9767, modman i dowiązania symboliczne

5) app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED at 36. Hunk # 2 FAILED at 54. 2 z 2 hunks FAILED: SUPEE-9767 Error

6) 1 na 1 przystojniak NIE POWIODŁO - zapisywanie odrzuceń do pliku app / code / core / Mage / Sales / Model / Quote / Item.php: Magento 1.9.2.2 SUPEE-9767 ERROR

7) błąd kasowania onestep (znowu jest to kwestia klucza formularza): SUPEE-9767 Magento CE 1.9.3.3 Kasowanie Onestep nie działa z włączoną funkcją Walidacja klucza formularza przy kasie

8) Kwestia rejestracji klienta w jednym kroku: SUPEE-9767 Patch / CE 1.9.3.3 - Kasa z jedną stroną - Problem z rejestracją klienta

9) app / code / core / Mage / Core / Model / File / Validator / Image.php: Magento SUPEE 9697 1.9.2.2 nie działa w Image.php

Zauważ, że Symlinks zawsze były domyślnie wyłączone w nowych instalacjach Magento administrator. TAK / NIE wartości konfiguracyjne domyślnie ustawione na „NIE”. Aktualizacja teraz wyraźnie wyłącza dowiązania symboliczne w config.xml i jako dodatkowe zabezpieczenie usuwa również sekcję szablonu z admin-> programisty, która zawierała opcję konfiguracji.

Nie wpłynie to na twoje obecne ustawienia dowiązań symbolicznych, jeśli ręcznie włączysz dowiązania symboliczne przed wersją 1.9.3.2, pozostaną włączone, chociaż ustawienia nie widać już w adminie.

Użytkownicy używający modmana do zarządzania modułami Magento 1.x powinni upewnić się, że nie wyłączają dowiązań symbolicznych, ponieważ spowoduje to wyłączenie modułów modmana.

Odpowiedzialni administratorzy mogą ponownie włączyć sekcję admin dowiązania symbolicznego, szukając zmian różnic w sekcji szablonów w app / code / core / Mage / Core / etc / system.xml i dodając sekcję do pliku system.xml około linii 600. Lub dowiązania symboliczne podwójnego sprawdzania są nadal włączone przy pomocy

n98-magerun.phar config: dump | symp grep

Oto plik różnic dla magento1933 i magento1932, aby pomóc w zidentyfikowaniu zmian w domyślnym motywie, które mogą wpłynąć na twoje niestandardowe / rozszerzone motywy.

diff -r magento1933 magento1932> https://pastebin.com/ADzMBLhr

Problem: używanie php7 czasami powoduje następujący błąd:

Decoding failed: Syntax error

#0 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(179): Zend_Json::decode('')
#1 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(215): Enterprise_PageCache_Model_Observer->_loadDesignExceptions()
#2 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(125): Enterprise_PageCache_Model_Observer->_saveDesignException()
#3 /______/app/code/core/Mage/Core/Model/App.php(1358): Enterprise_PageCache_Model_Observer->cacheResponse(Object(Varien_Event_Observer))
#4 /______/app/code/core/Mage/Core/Model/App.php(1337): Mage_Core_Model_App->_callObserverMethod(Object({custom extensio}_Model_Rewrite_PageCache_Observer), 'cacheResponse', Object(Varien_Event_Observer))
#5 /______/app/Mage.php(456): Mage_Core_Model_App->dispatchEvent('controller_fron...', Array)
#6 /______/app/code/core/Mage/Core/Controller/Varien/Front.php(182): Mage::dispatchEvent('controller_fron...', Array)
#7 /______/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#8 /______/app/Mage.php(691): Mage_Core_Model_App->run(Array)
#9 /______/index.php(105): Mage::run('brandfield_nl', 'store')
#10 {main}

Jest całkiem pewne, że wersja Zend musi coś z tym zrobić. Jest to szybka poprawka, ale na pewno nie jest poprawna:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 zamień na:

    if ($cachedSslOffloaderHeader !== false) {
        $cachedSslOffloaderHeader = trim(@Zend_Json::decode($cachedSslOffloaderHeader));
    }

-> i app / code / core / Enterprise / PageCache / Model / Observer.php: 177 z:

    if ($exceptions !== false) {
        $exceptions = Zend_Json::decode($exceptions);
    }

Oczywiście stwórz dodatek, aby to przepisać. Ale jestem pewien, że jest coś lepszego do zrobienia.

AKTUALIZACJA (lepsze rozwiązanie)

-> Idź do: lib / Zend / Json.php i po linii 76 dodaj:

    if ((float)phpversion() >= 7.0
        && empty($encodedValue)
    ) {
        return null;
    }

Utwórz rozszerzenie, aby je zastąpić i nie edytować pliku podstawowego.

Problem: kod dynamiczny lub css wyłącza kluczowy element wejściowy przy kasie

Problem Widziałem gdzie kod dynamiczny (paypal plus) w procesie zamawiania jednej stronie nadpisuje fieldset element w jednym etapie sposobu płatności formularza HTML - usunięcie lub wyłączenie (z CSS) ukryty form_key element.

Poprawka polega na tym, aby element formkey nie był wyłączany przez kod dynamiczny lub css. Przeniesienie kodu formkey poza fieldset elementu może również pomóc

<form>
    <?php echo $this->getBlockHtml('formkey') ?>
    <fieldset>
        <?php echo $this->getChildHtml('methods') ?>
    </fieldset>
</form>

Możesz łatwo sprawdzić, czy klucz_formatowy jest wykrywany i wysyłany do kontrolera jednostronicowego, sprawdzając żądania sieciowe ajax w przeglądarce podczas przechodzenia przez metody kasy, każda metoda powinna zawierać klucz formularza w danych formularza ajax, jeśli formularz klucz nie istnieje, ale kod źródłowy Magento został załatany. Sprawdź, czy kod zewnętrzny wpływa na element klucza formularza, tj. css lub dynamiczne zmiany po stronie klienta.

Problem: brakujące poprawki w pliku head-simple.phtml

app/design/adminhtml/default/default/template/oauth/authorize/head-simple.phtml

wymagają takich samych poprawek jak

app/design/adminhtml/default/default/template/page/head.phtml

PROBLEM: rejestracja klienta kończy się niepowodzeniem podczas korzystania z ogólnej 5-etapowej kasy Magento.

Ten problem jest prezentowany tylko wtedy, gdy WŁĄCZAMY uwierzytelnianie klucza formularza. Użyta wersja: 1.7.0.2, ale wygląda na to, że ktoś opublikował ten sam problem również w wersji 1.9.3. SUPEE-9767 Patch / CE 1.9.3.3 - Zamówienie jednej strony - Problem z rejestracją klienta

Kiedy Idź do kasy, mamy 2 opcje: KASA JAKO GOŚĆ LUB REJESTRACJA Po kliknięciu „Zarejestruj się” i wypełnieniu formularza wraz z hasłem, wykonujesz wszystkie kroki i realizujesz zamówienie. Zamówienie zostaje złożone, ALE klient nigdy nie zostaje zarejestrowany w Magento. Wygląda na to, że gość złożył zamówienie.

Kiedy wróciłem i wyłączyłem uwierzytelnianie przy użyciu klucza i próbowałem złożyć zamówienie podczas rejestracji jako klient, zostało ono złożone bez żadnych problemów, a klient został zarejestrowany w backend.

AKTUALIZACJA 13/07/2017 [PROBLEM JEST USUNIĘTY]

Zespół Magento wydał SUPEE-9767 V2 w tej wersji łatki problem z przezroczystymi gif i png został naprawiony.

Powinieneś przywrócić wszystkie zmiany do pliku omówionego w tym wątku. Następnie cofnij zastosowaną łatkę V1 i na koniec zastosuj nową wersję V2.

PRE - SUPEE-9767 V2

Nie używaj omawianego kodu, zamiast tego zastosuj V2 łatki. Problem omówiony poniżej został już rozwiązany w tej wersji

Jeśli ktoś ma problem z przezroczystymi png, że po przesłaniu z panelu administracyjnego tło staje się czarne. (Na produktach) odnosi się do wywołania zwrotnego przesyłania obrazu wprowadzonego w:

app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

W tej chwili nie jestem pewien, co dokładnie powoduje to zachowanie, ale próbuję to rozgryźć, mogę potwierdzić, że po usunięciu wywołania zwrotnego dziwne zachowanie zanika.

AKTUALIZACJA

Ok, znalazłem funkcję, która jest również zaktualizowana z SUPEE-9767, która faktycznie łamie przezroczystość w png, kopia oryginalnego obrazu jest tworzona bez przezroczystości.

+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
@@ -87,10 +87,33 @@ public function setAllowedImageTypes(array $imageFileExtensions = array())
      */
     public function validate($filePath)
     {
-        $fileInfo = getimagesize($filePath);
-        if (is_array($fileInfo) and isset($fileInfo[2])) {
-            if ($this->isImageType($fileInfo[2])) {
-                return null;
+        list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
+        if ($fileType) {
+            if ($this->isImageType($fileType)) {
+                //replace tmp image with re-sampled copy to exclude images with malicious data
+                $image = imagecreatefromstring(file_get_contents($filePath));
+                if ($image !== false) {
+                    $img = imagecreatetruecolor($imageWidth, $imageHeight);
+                    imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
+                    switch ($fileType) {
+                        case IMAGETYPE_GIF:
+                            imagegif($img, $filePath);
+                            break;
+                        case IMAGETYPE_JPEG:
+                            imagejpeg($img, $filePath, 100);
+                            break;
+                        case IMAGETYPE_PNG:
+                            imagepng($img, $filePath);
+                            break;
+                        default:
+                            return;
+                    }
+                    imagedestroy($img);
+                    imagedestroy($image);
+                    return null;
+                } else {
+                    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
+                }
             }
         }
         throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));

AKTUALIZACJA

Oto zaktualizowana wersja funkcji w celu zachowania przejrzystości png

  imagealphablending($img, false);
  imagesavealpha($img, true);

te dwie linie należy dodać do łatki. Zaktualizuj funkcję wapp/code/core/Mage/Core/Model/File/Validator/Image.php

/**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                imagealphablending($img, false);
                imagesavealpha($img, true);  
                imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

AKTUALIZACJA 23/06/17

Ta zaktualizowana wersja funkcji naprawia przezroczystość PNG i GIF.

    /**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagecolortransparent($img, imagecolorallocatealpha($img, 0, 0, 0, 127));
                        imagealphablending($img, false);
                        imagesavealpha($img, true);
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagealphablending($img, false);
                        imagesavealpha($img, true);  
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

Problem: Zezwalaj administratorom na wyświetlanie powiadomień symbolicznych

Powiadomienie dowiązaniem symbolicznym nie będzie wyświetlane w obszarze powiadomień administratora, ponieważ nie jest zawarte w <block type="core/text_list" name="notifications" as="notifications">

Poprawka dla CE i EE poniżej:

--- app/design/adminhtml/default/default/layout/main.xml
+++ app/design/adminhtml/default/default/layout/main.xml
@@ -119,7 +119,8 @@ Default layout, loads most of the pages
<block type="adminhtml/cache_notifications" name="cache_notifications" template="system/cache/notifications.phtml"></block>
<block type="adminhtml/notification_survey" name="notification_survey" template="notification/survey.phtml"/>
<block type="adminhtml/notification_security" name="notification_security" as="notification_security" template="notification/security.phtml"></block>
-            </block>
+                <block type="adminhtml/checkout_formkey" name="checkout_formkey" as="checkout_formkey" template="notification/formkey.phtml"/></block>
+                <block type="adminhtml/notification_symlink" name="notification_symlink" template="notification/symlink.phtml"/>
<block type="adminhtml/widget_breadcrumbs" name="breadcrumbs" as="breadcrumbs"></block>
<!--<update handle="formkey"/> this won't work, see the try/catch and a jammed exception in Mage_Core_Model_Layout::createBlock() -->

Problem znajduje </block>się na końcu checkout_formkey(który sam się kończy) i dlatego zamyka element nadrzędny notifications. Powoduje to, notification_symlinkże nie są uwzględniane core/text_listi nie są renderowane.

Mała wskazówka dla #patchday; po skopiowaniu 1.9.3.3 w instalacji, uruchom, git diff -w --stat | grep -v " 2 +" | grep -v " 0"aby szybko zobaczyć większe zmiany w plikach.

Problem: nie załatano szablonu wysyłki EE

Połączyłem instalację EE 1.13.1.0, a szablon wysyłki korporacyjnej ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) nie miał dodanego klucza form, ale szablony fakturowania i płatności tak.

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml został załatany.

Występuje problem z wersjami Magento EE z łatką SUPEE-9767 (więc nie z aktualizacjami do 1.14.3.3). Klucz formularza na tej stronie zostanie zapisany w pamięci podręcznej. Więc kiedy opróżnię pamięć podręczną, a następnie przejdę na stronę produktu i upewnię się, że strona jest całkowicie buforowana (odśwież kilka razy), powinienem móc dodać ten produkt do koszyka.

Teraz, gdy otworzę inną przeglądarkę (lub tryb incognito), otwórz tę samą stronę i spróbuj ponownie dodać produkt do koszyka. Produkt nie zostanie dodany do koszyka z powodu klucza formularza. Teraz, gdy ponownie opróżnisz pamięć podręczną, produkt można ponownie dodać do koszyka.

Dzięki Jasper Zeinstra

W przypadku programistów korzystających z Magento Composer Intaller możesz zmienić strategię wdrażania na Kopiuj zamiast Symlink. Możesz także skonfigurować dołączanie plików modułów do .gitignore, aby repozytorium pozostało czyste.

https://github.com/Cotya/magento-composer-installer/blob/master/doc/Deploy.md#deploy-per-copy-instead-of-symlink

{ "extra":{ "magento-root-dir": "htdocs/", "magento-deploystrategy": "copy", "auto-append-gitignore": true } }

Miałem problem z EE 1.14.2.2 z włączonym FPC i ta łatka została zastosowana.

Użytkownicy z przerwami nie mogli dodawać do koszyka.

Wyjaśnienie i naprawa tutaj: Problem SUPEE-9767: Problem z dodawaniem do koszyka, pamięć podręczna dla całej strony

Problem: Patch działał na waniliowym Magento 1.7.0.0 [edytowany]

Podczas testowania naszego skryptu poprawki wykryliśmy problem w łatce dla Magento 1.7.0.0. Nie wiem, czy ktoś nadal go używa, ale w każdym razie jest to problem w SUPEE-9767. Użyliśmy instalacji waniliowej i najpierw zainstalowaliśmy wszystkie poprzednie łaty.

Patch używany: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh Plik łata ma pracować dla Magento 1.7.0.1 i 1.7.0.2

Podsumowanie problemów:

ERROR: Patch can't be applied/reverted successfully.
...
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
...
checking file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED
...

Dla przypomnienia, to na 1.7.0.0 wypróbowaliśmy łatkę na:

$ grep SUPEE app/etc/applied.patches.list
2017-06-01 12:59:49 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
-e 2017-06-01 12:59:49 UTC | SUPEE-1049 | EE-1.12.0.2 | v1 | 6d06f286f461562fa6d6573349f1491f7bf89859 | Wed Feb 13 17:46:13 2013 -0800 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-01 12:59:49 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-01 12:59:49 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-01 12:59:49 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-01 12:59:49 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-01 12:59:49 UTC | SUPEE-6788 | CE_1.7.0.1 | v1 | 04d237d56b116989e46839c41691585d927f99db | Fri Oct 23 13:52:50 2015 +0300 | f69136a
2017-06-01 12:59:49 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-01 12:59:50 UTC | SUPEE-8788 | CE_1.7.0.0 | v2 | 6b5ef4fc5b09af74d0fd401440948d0a54dd203d | Fri Oct 14 19:27:22 2016 +0300 | 84fa3dd598466fa5c482965a3f8e5395af33bf9d
2017-06-01 12:59:50 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-01 12:59:50 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523

Musiałem tylko cofnąć tę łatkę z powodu dziwnego zachowania. Z jakiegokolwiek powodu niektórzy użytkownicy nie mogli dodawać niektórych produktów do koszyka.

Zakładam, że ma to coś wspólnego ze starymi ofertami kolidującymi z aktualną ofertą dla tego klienta. Zweryfikowałem ten problem, logując się jako użytkownik, aby upewnić się, że nie jest to tylko 1D10T.

To był problem, odkąd zabrałem życie w patchu w zeszły piątek. Używamy 1.14.2.4 . Jesteśmy mocno zmodyfikowani, więc może działać dobrze dla innych użytkowników. Tylko ostrzeżenie!

Problem: nieskończona pętla przekierowań w wersji 1.6.0.0

Szybka naprawa

Znajdź poniższe wiersze wewnątrz funkcji chronionej metodą _checkBaseUrl ($ request) w pliku app / code / core / Mage / Core / Controller / Varien / Front.php

 if (isset($uri['scheme']) && $uri['scheme'] != $request->getScheme()
        || isset($uri['host']) && $uri['host'] != $request->getHttpHost()
        || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) {  

Zmień te linie na

 if (isset($uri['host']) && $uri['host'] != $request->getHttpHost()
            || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) { 

Następnie zapisz plik (zatwierdzenie do REPO), wyczyść pamięć podręczną (usuń wszystko z folderu var / cache) i załaduj ponownie sklep. Powinieneś znaleźć ładowanie strony bez żadnych problemów z przekierowaniem 302 po zastosowaniu poprawki SUPEE 9767.

Przyczyna główna

Różnica wartości SCHEME między rzeczywistym żądaniem a identyfikatorem URI po przekierowaniu. Np .: Rzeczywiste żądanie zwraca schemat HTTP, ale schematem w URI może być HTTPS.

Możliwe przyczyny leżące u podstaw

1. Najprawdopodobniej możesz mieć regułę przekierowania w pliku .htaccess, aby przekierowywać wszystkie żądania http do https. Użytkownik prosi o adres http://twojadomena.com i być może zmieniłeś schemat i przekierowałeś go na https: // twojadomena zamiast http://twojadomena.com, o który tak naprawdę prosił.

2. Zarówno podstawowe bezpieczne, jak i niezabezpieczone adresy URL zaczynają się od https

BŁĄD POTWIERDZONY „Rejestracja klienta kończy się niepowodzeniem przy kasie” wystąpił po mojej stronie nieco inaczej.

Jeśli klient wybierze rejestrację w kasie, jego hasło nie zostanie poprawnie zapisane. Klient został utworzony poprawnie tylko dlatego, że hasło nie jest przechowywane. Wykryłem to przez fakt, że hasło nie było wyświetlane w powitalnym e-mailu. Ludzie też nie mogą się zalogować z tego powodu.

Poprawka powiązana z poprawką SUPEE-9767 / CE 1.9.3.3 - Kasa z jedną stroną - Problem z rejestracją klienta również wykonał to zadanie.

Czy ktoś może mi powiedzieć, po co to ... do ... w supee-9767?

Łatka nie działa nawet dla waniliowego Magento 1.7.0.2.

martins@martinsmac.local:/var/www/magento1702-original$ ./PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Mage/Admin/Model/Session.php
Hunk #1 succeeded at 109 (offset -29 lines).
patching file app/code/core/Mage/Adminhtml/Block/Checkout/Formkey.php
patching file app/code/core/Mage/Adminhtml/Block/Notification/Symlink.php
patching file app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Date.php
patching file app/code/core/Mage/Adminhtml/Model/Config/Data.php
patching file app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php
patching file app/code/core/Mage/Checkout/controllers/MultishippingController.php
patching file app/code/core/Mage/Checkout/controllers/OnepageController.php
Hunk #1 succeeded at 293 (offset -34 lines).
Hunk #2 succeeded at 313 (offset -34 lines).
Hunk #3 succeeded at 363 (offset -34 lines).
Hunk #4 succeeded at 392 (offset -34 lines).
Hunk #5 succeeded at 431 (offset -34 lines).
patching file app/code/core/Mage/Checkout/etc/system.xml
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/Controller/Front/Action.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 141 (offset -7 lines).
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
patching file app/code/core/Mage/Core/etc/config.xml
patching file app/code/core/Mage/Core/etc/system.xml
patching file app/code/core/Mage/Customer/Model/Session.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Adapter/Zend/Cache.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php
patching file app/code/core/Mage/ImportExport/Model/Import/Uploader.php
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file app/code/core/Mage/Widget/Model/Widget/Instance.php
patching file app/code/core/Mage/XmlConnect/Helper/Image.php
patching file app/design/adminhtml/default/default/layout/main.xml
patching file app/design/adminhtml/default/default/template/notification/formkey.phtml
patching file app/design/adminhtml/default/default/template/notification/symlink.phtml
patching file app/design/adminhtml/default/default/template/page/head.phtml
patching file app/design/frontend/base/default/template/checkout/cart/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/billing.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/billing.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/payment.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml
patching file app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml
patching file app/etc/config.xml
patching file app/locale/en_US/Mage_Adminhtml.csv
patching file app/locale/en_US/Mage_Core.csv
patching file app/locale/en_US/Mage_Dataflow.csv
patching file downloader/Maged/Connect.php
patching file downloader/Maged/Controller.php
Hunk #1 succeeded at 400 (offset -5 lines).
Hunk #2 succeeded at 923 (offset -5 lines).
patching file downloader/Maged/Model/Session.php
Hunk #2 succeeded at 235 with fuzz 2 (offset -13 lines).
patching file js/varien/payment.js
patching file skin/frontend/base/default/js/opcheckout.js

nawet po ręcznym nałożeniu starszych łatek.

$ grep '|' app/etc/applied.patches.list
2017-06-19 04:01:42 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-19 04:03:26 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
2017-06-19 04:04:12 UTC | SUPEE-1049 | EE_1.12.0.2 | v1 | 5cd884653325315804056d4c591572385b3c1d03 | Thu Mar 20 16:33:19 2014 +0200 | v1.12.0.2..HEAD
2017-06-19 04:05:01 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-19 04:06:38 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-19 04:07:10 UTC | SUPEE-1533 | EE_1.12 | v1 | _ | n/a | SUPEE-1533_EE_1.12_v1.patch
2017-06-19 04:08:41 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-19 04:09:29 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-19 04:10:00 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-19 04:11:22 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-19 04:11:50 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-19 04:12:12 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-19 04:14:30 UTC | SUPEE-8167 | EE_1.12.0.2 | v1 | b1be28f9cd8c2ecba2aa403e59ad9e3d2855eb95 | Thu May 4 13:52:13 2017 +0300 | 8d12ea6fe564b6dc9ed1affb6de990f81aca3796..HEAD
2017-06-19 04:16:21 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-19 04:16:44 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
2017-06-19 04:19:35 UTC | SUPEE-6788 | CE_1.7.0.2 | v1 | 0398c4b951d9a0f64495e7b8b3b8ca480952dd70 | Fri Oct 23 13:50:23 2015 +0300 | cfc252b

Rozwiązaniem / problemem, który znalazłem, jest to, że niektóre zmiany w łatce dla wersji 1.7.0.2 dotyczą plików, które nie istniały przed wersją 1.9.2.3. Skopiowałem więc następujące pliki z zupełnie nowej instalacji 1.9.2.3 przed uruchomieniem skryptu poprawki:

• app / code / core / Mage / Core / Model / File / Validator / Image.php
• app / code / core / Mage / Sales / Model / Quote / Item.php

Po prostu dodaj do https://magento.stackexchange.com/a/176930/46249

Zauważ, że Symlinks zawsze były domyślnie wyłączone w nowych instalacjach Magento administrator TAK / NIE wartości konfiguracyjne domyślnie ustawione na „NIE”. Aktualizacja teraz wyraźnie wyłącza dowiązania symboliczne w config.xml i jako dodatkowe zabezpieczenie usuwa również sekcję szablonu z admin-> programisty, która zawierała opcję konfiguracji.

Nie wpłynie to na twoje obecne ustawienia dowiązań symbolicznych, jeśli ręcznie włączysz dowiązania symboliczne przed wersją 1.9.3.2, pozostaną włączone, chociaż ustawienia nie widać już w adminie.

Pogrubiony tekst jest niepoprawny. W przypadku aktualizacji do wersji 1.9.3.4 (SUPEE-9767 V2) lub nowszych bieżących ustawień zostaną usunięte:

# app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.6-1.6.0.7.php
$connection->delete(
    $this->getTable('core_config_data'),
    $connection->prepareSqlCondition('path', array(
        'like' => 'dev/template/allow_symlink'
    ))
);

Odpowiedzialni administratorzy mogą ponownie włączyć sekcję admin dowiązania symbolicznego, szukając zmian różnic w sekcji szablonów w app / code / core / Mage / Core / etc / system.xml i dodając sekcję do pliku system.xml około linii 600. Lub dowiązania symboliczne podwójnego sprawdzania są nadal włączone za pomocą

Po prostu wyświetl ponownie opcję konfiguracji nie rozwiąże problemu. Opcja pojawia się, ale nie możesz zmienić konfiguracji, ponieważ nowo wprowadzony model zaplecza uniemożliwia zapisanie wartości. Widzieć:

# app/code/core/Mage/Core/etc/system.xml
<backend_model>adminhtml/system_config_backend_symlink</backend_model>

i

# Mage_Adminhtml_Model_System_Config_Backend_Symlink
public function save()
{
    return $this;
}

Więc musisz usunąć lub zastąpić ten model zaplecza, zobacz Jak włączyć dowiązania symboliczne po instalacji SUPEE-9767 V2?