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

108

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.

Ryan Hoerr
źródło
„Siedem z 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”. Chciałem tylko sprawdzić, czy „atakujący” musi uzyskać dostęp do administratora, aby wykonać którekolwiek z tych exploitów?
PaddyD
3
tak, musisz mieć dostęp administratora, aby móc wykorzystać ...
MagenX
Wydaje się, że łatka nie zatrzymuje wspólnego punktu końcowego brutalnej siły (tj. / Rss / order / new), który wydaje się być najczęstszym sposobem, w jaki osoby próbujące uzyskać dostęp do obszarów administracyjnych?
Ricky Odin Matthews
1
Używam tego dla RSS @RickyOdinMatthews w .htaccess RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC]
Richard Feraro
@RichardFeraro Używam nginx, ale już używam podobnego rozwiązania. Zauważyłem, że boty zwykle skanują w poszukiwaniu punktów końcowych.
Ricky Odin Matthews

Odpowiedzi:

107

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:

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.

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.

Raphael at Digital Pianism
źródło
1
@Icon nope. Aby sprawdzić dwukrotnie, użyj narzędzia, o którym wspomniałem u góry mojej odpowiedzi
Raphael at Digital Pianism
1
żeby dodać do listy „innych problemów”: wygląda na to, że magento.stackexchange.com/questions/167616/... również nie jest naprawiony w najnowszej wersji
Anton Boritskiy
1
@RaphaelatDigitalPianism: magento.stackexchange.com/q/177560/51361
1
Kolejny dodatek do listy: łatka przerywa multipipping dla domyślnego motywu magento.stackexchange.com/questions/177681/…
Aad Mathijssen
1
„Znak wodny ma czarne tło, gdy jest przezroczysty” - może potwierdzić, że ten jest poprawny. Dzieje się tak, gdy prześlesz dowolny przezroczysty png w cms
pixiemedia
42

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/

Amit Bera
źródło
1
Przyjemny i szybki jeden wiersz do znalezienia niestandardowych plików szablonów dla klucza formularza w kasie; znajdź aplikację / design / frontend | grep -E "kasa / onepage / (fakturowanie | płatność | wysyłka | wysyłka_metoda) .phtml" | grep -v "base / default" | grep -v "rwd / default"
Peter Jaap Blaakmeer
6
lub zaktualizuj je natychmiast, używając nieco dłuższego linera
Fabian Schmengler
to jest magia @FabianSchmengler !!! :)
Amit Bera
@FabianSchmengler niesamowite, działało!
Peter Jaap Blaakmeer
1
@AmitBera FYI: niektóre wtyczki kasy używają AJAX do przesyłania faktur / wysyłki / itp. Po prostu musiałem załatać jeden. Prostym sposobem na to jest umieszczenie <script> var formKey = "<? Php echo Mage :: getSingleton ('core / session') -> getFormKey ();?>"; </script> na czele tematu. Następnie możesz dodać form_key: formKey jako parametr do przesłania AJAX. Oczywiście przetestuj formularze po, aby potwierdzić przesłanie nowego parametru i edytuj Kontroler, aby obsługiwał go tak, jak wspomniano w poście.
Kalvin Klien
26

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.
mpchadwick
źródło
1
Możesz też po prostu wejść z edytorem szesnastkowym i dodać go do bazy danych, ale dla większości osób może to być trochę więcej
kot
1
Jeśli niektórzy z was używają CDN, np. Cloudflare, pamiętajcie o wyczyszczeniu pamięci podręcznej. Próbowałem przejść przez kasę przy aktywnym CDN i nie przejdzie ona obok strony Płatności. W momencie wyczyszczenia pamięci podręcznej i włączenia trybu programowania wszystko poszło dobrze.
Ikona
14

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

Murtuza Zabuawala
źródło
1
Wersja 2 łatki powinna być dostępna wkrótce. Błędy powinny zostać naprawione.
Ikona
1
@icon czeka na v2
Murtuza Zabuawala
9

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

paj
źródło
Dlaczego usunęli opcję Symlinks ?, czy jest teraz exploit otwarty dla publiczności (poza użytkownikiem administracyjnym), czy jest to tylko ryzyko, jeśli jest w środowisku współdzielonym?
PaddyD
Ten wątek wydaje się odpowiedzieć na moje pytanie: magento.stackexchange.com/questions/176952/...
PaddyD
Dowiązania symboliczne są wyłączone z określonego powodu. Proponuję skopiować zamiast dowiązania symbolicznego: magento.stackexchange.com/a/177149/54863
Barryvdh
9

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.

folektoras133
źródło
Pamięć podręczna została całkowicie wyczyszczona. To nie jest ten sam problem.
folektoras133
2
Dotknęliśmy tego samego problemu - przywrócenie aplikacji / kodu / rdzenia / Enterprise / PageCache / Model / Observer.php usunęło problem, ale oczywiście nie jest to poprawna poprawka, po prostu zapobieganie a:5:{i:0;s:29:"Decoding failed: Syntax error";i:1;s:1376:"#0 app/code/core/Enterprise/PageCache/Model/Observer.php(177): Zend_Json::decode('a:0:{}')
Judder
9

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.

wprowadź opis zdjęcia tutaj

paj
źródło
2
Ta poprawka nie działała dla mnie w EE. Odkryłem, że plik również app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml musi zostać zaktualizowany: linie 35-38 muszą zostać zaktualizowane, aby uwzględnić || elements[i].name == 'form_key'wraz z innymi selektorami, aby pole formularza form_key było wyłączone.
Greg Nickoloff,
Dzięki g-man1066! To był dokładnie problem, który miałem.
grafikchaos
9

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
William Tran
źródło
Dla tych, którzy szukają, ta poprawka jest; github.com/nathandcornell/magento-patches/blob/…
Peter Jaap Blaakmeer
8

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.

Ikona
źródło
1
Oto bardziej szczegółowy post na ten temat magento.stackexchange.com/questions/177035/...
Raphael at Digital Pianism
8

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.

wprowadź opis zdjęcia tutaj

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.'));
}
Daniel Yovchev
źródło
1
To rozwiązało mój problem w instalacji Magento 1.7. Dzięki!
Tjitse
Nie ma problemu, Tjitse po prostu zanotuje tę zmianę, na wypadek, gdyby zespół Magento nie naprawił łatki, będziesz musiał ją cofnąć podczas wykonywania następnej łatki. Problem został przesłany społeczności na stronie bugcrowd.com, mając nadzieję, że wkrótce wprowadzą poprawkę.
Daniel Yovchev
to naprawia to dla pngs, ale nie dla przezroczystych plików gif. Pliki gif wymagają nieco innej obsługi przy użyciu imagecolortransparent
zaktualizuj
Dziękujemy za zwrócenie uwagi na to, aby zobaczyć zaktualizowaną funkcję, która naprawia również przezroczystość gif.
Daniel Yovchev
7

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.

Mwylde
źródło
To nie jest tak naprawdę problem, powiadomienie zostało usunięte, ponieważ dowiązania symboliczne zostały wyraźnie wyłączone, a sekcja konfiguracji dowiązań symbolicznych została usunięta. W wersji v1933 nie można ręcznie zmienić wartości dowiązania symbolicznego, dlatego wyświetlanie powiadomienia administratora jest raczej bezcelowe. Problem dotyczy nowych instalacji z 1933 r., W których użytkownicy, którzy wymagają dowiązań symbolicznych, tj. Modmana, nie mogą już ręcznie włączyć go. Można wywnioskować, że Magento nie spodziewa się żadnych nowych instalacji 1.x ...
paj
Nie zgadzam się, ta poprawka nie wyłącza wyraźnie konfiguracji, jeśli jest już ustawiona - wyłącza ją tylko, jeśli nie jest już ustawiona. Dlatego jeśli instancja ma dev / template / allow_symlink ustawioną na wartość tak w DB / local.xml przed tą łatką i zastosuje łatkę, POWINIEN otrzymać ostrzeżenie, że dowiązania symboliczne są dozwolone, ponieważ są potencjalnie podatne na atak.
mwylde
Rozumiem twój punkt widzenia i masz rację. Ale dla zwykłego użytkownika, co by wtedy zrobili - nie można ręcznie wyłączyć go z poziomu administratora, ponieważ opcja konfiguracji została usunięta. To trochę sytuacja z złapaniem 22 ...
paj
7

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.

Peter Jaap Blaakmeer
źródło
7

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.

Laura
źródło
Potrzebowałem również (dla EE 1.14.2), aby dodać form_key do /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtml,.../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml
Greg Nickoloff
4

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

Arjen Miedema
źródło
3

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

Barryvdh
źródło
Dowiedzieliśmy się, że z kopiowaniem "magento-force": true,staje się ważne
Jeroen
2

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
Jeroen Vermeulen - MageHost
źródło
4
Jeśli brakuje tego pliku, najprawdopodobniej nie zastosowano poprawki zabezpieczeń SUPEE-7405.
Ryan Hoerr
@RyanHoerr masz rację, SUPEE-7405 został pominięty, ponieważ oficjalny plik PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.shnie działa dla 1.7.0.0. Utworzyłem poprawioną wersję pliku. Jeśli ktoś tego potrzebuje, wyślij mi wiadomość.
Jeroen Vermeulen - MageHost
2

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!

Uczeń jednego
źródło
Zgadza się, łatka przerywa działanie dodawania do koszyka dla wersji EE Magento. Zasadniczo problem występuje, ponieważ moduł PageCache ma jedną wersję logiki generowania form_key, podczas gdy sesja ma swoją własną. Gdy FPC ma buforowaną wersję żądanej strony, ale musi zregenerować minicart, uruchamiana jest sesja, która regeneruje klucz_formatowy w tym samym czasie, gdy wywoływane jest zapisywanie FPC, które generuje własny klucz_formatowy. W tym momencie wartość sesji form_key różni się od wartości przechowywanej w pliku cookie klienta (używanym w procesorze FPC), więc otrzymujesz nieprawidłowy klucz przy dodawaniu do kontrolera koszyka.
Stjepan
Mam również ten problem. Dam ci znać, jeśli znajdę rozwiązanie.
cmtickle
Rozwiązałem ten problem, wyjaśnienie tutaj: magento.stackexchange.com/questions/177942/…
cmtickle
Czy ktoś wie, czy problem został rozwiązany w SUPEE-9767 v2?
Uczeń z
2

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

Haijerom
źródło
2

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.

ahe_borriglione
źródło
2

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

wprowadź opis zdjęcia tutaj

Detzler
źródło
1
Wersja jQuery 1.10.2 jest uważana za podatną na atak i oznaczoną przez niektóre skanery PCI. Wersja 1.12 nie jest.
Ryan Hoerr
@Detzler StackExchange nie jest forum. Jeśli chcesz zadać pytanie, powinieneś je zadać, a nie odpowiedź na pytanie.
toon81
1
Ryan Hoerr zapytał o wszelkie problemy związane z łatką. Więc powiedziałem mu o możliwej przełomowej zmianie, jak widać na zrzucie ekranu. Nie potrafię wyjaśnić przyczyny tej zmiany. Więc zapytałem sub. Więc jaki masz problem?
Detzler
2

Ł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
Ricardo Martins
źródło
Łata zakłada, że ​​wszystkie inne poprawki bezpieczeństwa zostały już zastosowane. Pliki, o których mówisz, zostały dodane / zmienione przez poprzednie łaty. Brakuje Ci co najmniej SUPEE-7405.
Ryan Hoerr
Cześć Ryan, W rzeczywistości próbowałem również zastosować 7405, ale też nie działałem ... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52 \ (1) .sh Sprawdzanie, czy łatka może zostać pomyślnie zastosowana / cofnięta ... BŁĄD: Poprawki nie można pomyślnie zastosować / przywrócić. (..) Adminhtml / Helper / Sales.php Hunk # 1 FAILED at 121. 1 z 1 hunk FAILED - zapisywanie odrzuceń do pliku (..) Adminhtml / Helper / Sales.php.rej łatanie pliku (..) / Core / Model / Config.php Hunk # 1 FAILED at 1642. 1 z 1 hunk FAILED - zapisywanie odrzuceń do pliku (..) Plik łatania Config.php.rej (..) / Quote / Item.php Hunk # 1 FAILED at 509 ....
Ricardo Martins
@ RicardoMartins jak mogę rozwiązać ten błąd: łatanie pliku app / locale / en_US / Mage_Adminhtml.csv Hunk # 2 FAILED o 36. 1 z 2 porcji FAILED - zapisywanie odrzuceń do pliku app / locale / en_US / Mage_Adminhtml.csv.rej ?
zus
0

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?

sv3n
źródło