Sicherheitspatch SUPEE-9767 - Mögliche Probleme?


108

Für Magento 1 ist ein neuer Sicherheitspatch verfügbar, der 16 APPSEC-Probleme behebt: https://magento.com/security/patches/supee-9767

Sieben der Sicherheitsanfälligkeiten haben einen CVSSv3-Schweregrad von 8,0 oder höher und werden in der Natur ausgenutzt. Dies ist also ein kritischer Patch. Sites können SUPEE-9767 anwenden oder auf die neue Version CE 1.9.3.3 / EE 1.14.3.3 aktualisieren.

Auf welche häufigen Probleme oder Fallstricke ist bei der Anwendung von SUPEE-9767 zu achten?


UPDATE 12.07.2017:

Magento hat SUPEE-9767 V2 und CE 1.9.3.4 veröffentlicht , um viele der Probleme ab dem ersten Patch zu beheben . Wenn Sie V1 angewendet haben, sollten Sie V2 zurücksetzen und dann anwenden. Wenn Sie noch nicht gepatcht haben, wenden Sie einfach V2 an, und die meisten der hier angesprochenen Probleme sind nicht relevant.


"Sieben der Sicherheitsanfälligkeiten haben einen CVSSv3-Schweregrad von 8,0 oder höher und werden in der Natur ausgenutzt. Dies ist also ein kritischer Patch." Ich wollte nur überprüfen, ob der "Angreifer" in den Admin-Bereich gelangen muss, um einen dieser Exploits auszuführen.
PaddyD

3
Ja, Sie müssen über Administratorrechte verfügen, um Exploit
ausführen

Der Patch scheint den gemeinsamen Brute-Force-Endpunkt jedoch nicht zu stoppen (dh / rss / order / new). Dies scheint die häufigste Methode zu sein, mit der Bottler versuchen, Zugang zu Admin-Bereichen zu erhalten.
Ricky Odin Matthews

1
Ich benutze dies für RSS @ RickyOdinMatthews in .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 Ich benutze nginx, benutze aber schon eine ähnliche Lösung. Ich habe bemerkt, dass Bots normalerweise nach diesen Endpunkten suchen und sie brutal erzwingen.
Ricky Odin Matthews

Antworten:


107

Hier ist meine Übersicht über den Patch, nachdem ich ihn gelesen habe

ZEIT SPAREN : Experius bietet einen Patch-Helfer, mit dem Sie die Dateien in benutzerdefinierten Designs, benutzerdefinierten Modulen oder lokalen Überschreibungen finden können, die möglicherweise auch manuell gepatcht werden müssen. Sie finden ihn hier: https://github.com/experius/Magento- 1-Experius-Patch-Helper # magento

Checkout-Formularschlüssel

Wie im anderen Beitrag bereits erwähnt, fügt dieser Patch den folgenden Formularen Formularschlüssel hinzu:

Versand Warenkorb Formular:

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

Multishipping-Abrechnungs-Checkout-Formular:

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

Multishipping Versandkasse Formular:

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

Bestellformular für Multishipping-Adressen:

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

Rechnungs-Checkout-Formular:

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

Versand-Bestellformular:

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

Zahlungskasse:

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

Versandart Bestellformular:

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

Persistent Billing Checkout-Formular:

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

Darüber hinaus wurden die folgenden JS-Dateien aktualisiert, um mit dieser Änderung kompatibel zu sein:

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

Was ist zu tun:

Wenn Sie benutzerdefinierte Versionen dieser Vorlagen verwenden, müssen Sie diese aktualisieren, indem Sie den folgenden Code hinzufügen:

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

Wenn Sie ein Checkout-Modul eines Drittanbieters verwenden, müssen Sie sich mit diesen in Verbindung setzen, damit sie eine aktualisierte Version ihres Moduls bereitstellen können.

Auch wenn Sie benutzerdefinierte Versionen der zuvor aufgelisteten JS-Dateien haben, müssen Sie diese ebenfalls aktualisieren.

SPAREN SIE IHRE ZEIT :

Fabian Schmengler hat ein nettes kleines Skript geschrieben, um all diese Dinge für Sie zu aktualisieren. Sie finden es hier:

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

WICHTIGER HINWEIS : Die Kasse formkey Validierung über ein neues Konfigurationsfeld unter im Backend geändert wird System> Configuration> Admin> Sicherheit> aktiviert Formular Key Validierung Kasse . DIES IST NICHT STANDARDMÄSSIG AKTIVIERT, daher müssen Sie es aktivieren, um von dieser Sicherheitsfunktion zu profitieren !!! Beachten Sie, dass Sie eine Benachrichtigung im Backend erhalten, wenn es nicht aktiviert ist.

Rückruf zum Hochladen von Bildern

Der Bildergalerie-Controller wurde aktualisiert, um einen Validierungs-Callback hinzuzufügen.

Was ist zu tun

Wenn Sie ein benutzerdefiniertes Modul verwenden, das das Hochladen von Bildern mit folgendem Code ausführt:

        $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);

Ich empfehle dringend, dass Sie diesen Code aktualisieren, indem Sie das folgende Stück danach hinzufügen:

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

Symlinks

Dieser Patch entfernt das Systemkonfigurationsfeld, mit dem Sie Vorlagen-Symlinks im Backend zulassen können. Früher war es unter System> Konfiguration> Entwickler> Vorlage> Symlinks zulassen . Jetzt ist der gesamte Vorlagenbereich verschwunden.

Darüber hinaus ist dieses Feld jetzt standardmäßig über die Schaltfläche deaktiviert app/etc/config.xml

Das Komische dabei ist, dass Sie eine Benachrichtigung im Backend erhalten, wenn Sie dieses Konfigurationsfeld vor dem Patch aktiviert haben, es jedoch nicht deaktivieren können, da das Feld nicht mehr vorhanden ist.

Die einzige Möglichkeit besteht darin, die folgende SQL-Abfrage auszuführen

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

Klärung

Zuerst empfehle ich Ihnen dringend, die beiden Posts zu überprüfen, die Ihnen helfen, den Zweck dieser Symlink-Änderung zu verstehen:

Bei dieser Änderung geht es wirklich darum, hochladbare Inhalte (wie Bilder) über Vorlagenanweisungen aufzurufen.

Das Problem im Zusammenhang mit Symlinks ist nur mit Administratorzugriff ausnutzbar, und Magento hat auch beim Hochladen von Bildern etwas mehr Schutz hinzugefügt.

Bitte beachten Sie, dass es sich um einige Schutzmaßnahmen gegen die bekannte Art und Weise handelt, es zusätzlich zur Einstellung selbst auszunutzen.

Was zu tun ist : Wenn Sie wie ich Modman oder Composer mit Template-Symlinks verwenden, treten einige Probleme auf. Ich versuche immer noch herauszufinden, was hier am besten ist, abgesehen von der Bearbeitung von SQL-Abfragen.

Hauptbeitrag zu diesem Thema: SUPEE-9767, Modman und Symlinks

Liste möglicher Probleme

V2 wurde seit diesem ursprünglichen Beitrag veröffentlicht. Vergessen Sie nicht zu aktualisieren

Bugs

Das Wort "Bestätigt" wird für bestätigte Fehler verwendet. Wenn es nicht vorhanden ist, bedeutet dies, dass es sich möglicherweise um einen Fehler handelt, der jedoch noch nicht bestätigt wurde.

Probleme mit Hunk-Fehlern

Beachten Sie, dass all diese Probleme einfach daran liegen können, dass Sie die Originaldatei geändert haben, um zu überprüfen, ob dies nicht der Fall ist:

  • Sichern Sie die Datei, in der der Fehler "Hunk Failed" angezeigt wird
  • Laden Sie die Originaldatei von Ihrer Magento-Version herunter
  • Vergleichen Sie beide Dateien

Wenn sich die Dateien unterscheiden, müssen Sie den Patch mit der Originaldatei anwenden. Wenden Sie dann Ihre benutzerdefinierten Änderungen auf saubere Weise erneut an, z. B .:

  • benutzerdefinierte Vorlage in einem benutzerdefinierten Themenordner
  • local.xml
  • App / Code / lokale Datei

Wenn sich die Dateien nicht unterscheiden, handelt es sich entweder um ein Berechtigungsproblem oder um einen "Bug" im Patch.


1
@Icon Nein. Verwenden Sie zur Überprüfung das Tool, auf das ich oben in meiner Antwort
verwiesen

1
Nur um die Liste der "anderen Probleme" zu erweitern: Es scheint, dass magento.stackexchange.com/questions/167616/… nicht auch in der neuesten Version behoben ist
Anton Boritskiy,

1
@RaphaelatDigitalPianism: magento.stackexchange.com/q/177560/51361

1
Ein weiterer Zusatz zur Liste: Der Patch unterbricht das Multishipping für das Standardthema magento.stackexchange.com/questions/177681/…
Aad Mathijssen,

1
'Wasserzeichen erhalten schwarzen Hintergrund, wenn es transparent ist' - kann bestätigen, dass dieses korrekt ist. Dies geschieht, wenn Sie ein transparentes PNG in
cms

42

Problem 1: form_key ungültig bei Checkout onepage

Magento fügt form_keyhöchstens die Formulare hinzu.

Wenn ja using default onepage and using custom theme, werden Sie form_keybei jedem Schritt ** beim Auschecken ** Probleme bekommen.

Sie sollten den Formularschlüssel unter hinzufügen <?php echo $this->getBlockHtml('formkey') ?>

Auschecken Schritt Dateien zu bilden, wenn unter Dateien beendet wird,

  • 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

Wenn die Vorlagendateien vom Basisthema aufgerufen werden , entsteht kein Problem. Weil der Patch diese Dateien automatisch aktualisiert.

Beachten Sie auch: <?php echo $this->getBlockHtml('formkey') ?>sollte immer innerhalb des Formular-Tags liegen

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

** Wenn Sie Magento Multi-Shipping Checkout verwenden, müssen Sie dies unter tun

unter Dateien:

Issue2: form_key Problem mit dem Versandschätzungsformular auf der Warenkorbseite:

Fügen Sie form_key beim Versand des Angebotsformulars auf der Warenkorbseite hinzu

Dann muss Formularschlüssel hinzufügen <?php echo $this->getBlockHtml('formkey') ?>

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

Problem 3: Magento Onepage Checkout opcheckout.js Fehler

Wenn Sie die standardmäßige Onepage-Prüfung verwenden und haben, opcheckout.js sollten Sie dies überprüfen

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {ist unter opcheckout.js verfügbar

Wenn nicht, dann ersetzen

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

mit

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

Für den Fall von Problem1, Problem2, Problem3 kann das Problem einfach mit dem Skript add-checkout-form-key.sh von @FabianSchmengler behoben werden . Dies behebt das Problem in Ihren empfangenen Themendateien

Problem 4: Ungültiger Formularschlüssel nach Kundenanmeldung beim Umschreiben von Mage_Customer_Model_Session

Wenn Mage_Customer_Model_SessionKlasse umschreiben oder abgerufen haben

app/code/local/Mage/Customer/Model/Session.phpDann kann es zu einem form_key-Problem kommen, wenn wir einen Kunden für die Sitzung mit setCustomerAsLoggedIn()/ oder nach einem in der Sitzung festgelegten Kunden festlegen.

In diesem Fall müssen Sie hinzufügen

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

bei setCustomerAsLoggedIn () vor dem Aufruf von

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

Issue5: Problem mit Form_key nach dem Abmelden

Nach dem Abmelden des Kunden von der Sitzung können Sitzungsprobleme auftreten, wenn die Mage_Customer_Model_SessionKlasse neu geschrieben wurde oder von aufgerufen wurde

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

In der gleichen Notwendigkeit für diesen Fall:

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

Empfehlung:

Empfehlung 1: Um das Problem von supee-9767 zu beheben , können Sie den Patch https://github.com/experius/Magento-1-Experius-Patch-Helper verwenden

Dies ist eine der besten Lösungen für den Moment.

Zuvor wird dringend empfohlen, Dateien und eine Datenbanksicherung oder eine vollständige Systemsicherung durchzuführen.


Empfehlung 2: Verwenden Sie die Patch-Funktion für Ihren ONESTEP CHECKOUT

Wir wissen, dass Patch Supee-9767 aus Sicherheitsgründen veröffentlicht wurde. Wenn Sie ONESTEP CHECKOUT verwenden, sollten Sie form_key validation zur SAVE-Aktion Ihres Onestep Checkout-Controllers hinzufügen .

Angenommen, Sie möchten die Details der Versandmethode speichern, während Sie für Ihre Kaufabwicklung die Funktion saveShippingmethod () verwenden. Fügen Sie diese dann hinzu

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

Auch auf youmust hinzufügen Formular-Schlüssel <?php echo $this->getBlockHtml('formkey') ?> in Ihrem Onestep Checkout-Phtml-Dateien entsprechenden Abschnitt

Einige verwandte Links

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


1
Netter und schneller Einzeiler, um Ihre benutzerdefinierten Vorlagendateien für den Formularschlüssel beim Auschecken zu finden. find app / design / frontend | grep -E "checkout / onepage / (Rechnungsstellung | Zahlung | Versand | Versandmethode) .phtml" | grep -v "base / default" | grep -v "rwd / default"
Peter Jaap Blaakmeer

6
oder aktualisiere sie sofort mit einem etwas längeren Liner: gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b
Fabian Schmengler

das ist @FabianSchmengler Magie !!! :)
Amit Bera

@FabianSchmengler Super, das hat funktioniert!
Peter Jaap Blaakmeer

1
@AmitBera FYI: Einige Checkout-Plugins verwenden AJAX, um Rechnungen, Versand usw. einzureichen. Ich musste nur einen patchen. Eine einfache Möglichkeit ist, <script> var formKey = "<? Php echo Mage :: getSingleton ('core / session') -> getFormKey ();?>"; </ script> in den Kopf des Themas. Anschließend können Sie form_key: formKey als Parameter zur AJAX-Übermittlung hinzufügen. Testen Sie die Formulare anschließend, um die Übermittlung des neuen Parameters zu bestätigen, und bearbeiten Sie den Controller, um damit umzugehen, wie Sie es in Ihrem Beitrag erwähnt haben.
Kalvin Klien

26

Basierend auf meinem ersten Durchgang bei der Überprüfung der Patch-Datei ...

  • Eine neue Einstellung admin/security/validate_formkey_checkoutwurde hinzugefügt. Wenn diese Option aktiviert ist, werden Checkout-Formulare auf Vorhandensein eines Formularschlüssels überprüft. Wenn die Vorlagendateien im Design überschrieben werden, müssen sie dort aktualisiert werden. Diese Einstellung scheint standardmäßig deaktiviert zu sein
  • Symlinks scheinen standardmäßig (in app/etc/config.xml) nicht erlaubt zu sein . Außerdem scheint die Möglichkeit, sie zuzulassen, aus der Administratorkonfiguration entfernt worden zu sein. Wenn Ihre Site jedoch zuvor Symlinks explizit aktiviert hat, wird die Einstellung in der Datenbank gespeichert, wodurch diese Änderung außer Kraft gesetzt wird.
  • Sie müssen sowohl den Cache als auch den Ganzseiten-Cache leeren, wenn Sie diesen Patch anwenden. Die Entwurfsausnahmen werden in einem Format gespeichert, das mit der Dekodierung nicht kompatibel ist. Wenn Sie den Seiten-Cache nicht leeren, wird der folgende Fehler angezeigt: "Decodierung fehlgeschlagen: Syntaxfehler".

1
Sie können auch einfach mit einem Hex-Editor in die Datenbank gehen und ihn selbst hinzufügen, aber das mag für die meisten Leute ein bisschen viel sein
cat

1
Wenn einige von Ihnen CDN verwenden, z. B. Cloudflare, müssen Sie den Cache leeren. Ich habe versucht, über die Kasse zu gehen, während CDN aktiv war. Die Seite "Zahlungen" wurde nicht verlassen. In dem Moment, in dem ich den Cache geleert und den Entwicklungsmodus aktiviert habe, lief alles gut.
Icon

14

Unten base/defaultDatei mit diesem Patch betroffen, wenn diese Dateien in Ihrem Thema waren dann bitte entsprechend Änderungen

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

In allen obigen phtmlDateien wird die unterste Formular-Schlüsselzeile hinzugefügt. Bitte fügen Sie diese Zeile in Ihre jeweilige HTML-Datei ein.

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

Für die obige Ausgabe hat @fabian ein Skript erstellt, das den Formularschlüssel auch in Ihrer Designdatei hinzufügt

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

Wenn Sie nach dem Anwenden des Sicherheitspatches eine Fehlermeldung für den Formularschlüssel erhalten, können Sie diesen Patch anwenden. Der Vorgang zum Anwenden dieses Patches ist der gleiche wie für den Sicherheitspatch

  sh filename.sh

und eine base/defaultÄnderung in der JsDatei

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

Wenn diese jsDatei von Ihrem Design geladen wird, führen Sie die folgenden Schritte aus

Schlagleitung entfernen

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

und füge unterhalb der Zeile statt oberhalb hinzu

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

BEARBEITEN

Wenn Sie eine Checkout-Erweiterung verwenden, die die folgenden Dateien überschreibt, fügen Sie die Formularschlüsselzeile in die HTML-Datei der Checkout-Erweiterung ein.

EDIT2 - Probleme

1) Fehler bei saveBillingAction () oder beim Abrufen des Formularschlüssels null oder Problem mit dem Formularschlüssel: Patch 9767 erhält ungültigen Formularschlüssel

2) Hunk # 1 FEHLGESCHLAGEN bei 225. 1 von 1 Hunk FEHLGESCHLAGEN - Speichern von Ablehnungen in die Datei app / design / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml: SUPEE-9767 - Hunk # 1 FEHLGESCHLAGEN bei 225. 1 aus 1 Stück FEHLGESCHLAGEN

3) Speichern von Ablehnungen in der Datei app / code / core / Enterprise / PageCache / Model / Observer.php.rej: SUPEE-9767 FEHLER: Patch kann nicht erfolgreich angewendet / zurückgesetzt werden

4) SUPEE-9767, Modman und Symlinks: SUPEE-9767, Modman und Symlinks

5) app / design / frontend / rwd / default / layout / page.xml Hunk Nr. 1 ist bei 36 fehlgeschlagen. Hunk Nr. 2 ist bei 54 fehlgeschlagen. 2 von 2 Hunks sind fehlgeschlagen: SUPEE-9767 Fehler

6) 1 von 1 Hunk FEHLGESCHLAGEN - Speichern von Ablehnungen in Datei App / Code / Kern / Magier / Verkauf / Modell / Angebot / Item.php: Magento 1.9.2.2 SUPEE-9767-Patch FEHLER

7) Fehler beim Auschecken in einem Schritt (dies ist wiederum das Problem mit dem Formularschlüssel): SUPEE-9767 Magento CE 1.9.3.3 Onestep Checkout funktioniert nicht, wenn die Validierung des Formularschlüssels bei Auschecken aktiviert ist

8) Problem bei der Kundenregistrierung in einem Schritt: SUPEE-9767 Patch / CE 1.9.3.3 - One Page Checkout - Problem bei der Kundenregistrierung

9) app / code / core / mage / core / model / file / validator / image.php: Magento SUPEE 9697 1.9.2.2 schlägt bei image.php fehl


1
Version 2 des Patches sollte bald verfügbar sein. Bugs sollten behoben sein.
Icon

1
@icon Warten auf die v2
Murtuza Zabuawala

9

Beachten Sie, dass Symlinks in neuen Magento-Installationen standardmäßig immer deaktiviert waren. Die Konfigurationswerte für admin YES / NO lauten standardmäßig 'NO'. Das Update deaktiviert jetzt explizit Symlinks in config.xml und entfernt vorsichtshalber auch den Vorlagenbereich von admin-> developer, der die Konfigurationsoption enthielt.

Dies hat keine Auswirkungen auf Ihre aktuellen Symlink-Einstellungen. Wenn Sie Symlinks vor 1.9.3.2 manuell aktiviert haben, bleiben sie aktiviert, obwohl Sie die Einstellung in admin nicht mehr sehen können.

Benutzer, die Modman zum Verwalten von Magento 1.x-Modulen verwenden, sollten sicherstellen, dass Symlinks nicht deaktiviert werden, da dies die Modman-Module deaktiviert.

Verantwortliche Administratoren können den Symlink-Admin-Bereich wieder aktivieren, indem sie nach den unterschiedlichen Änderungen im Vorlagenbereich in app / code / core / Mage / Core / etc / system.xml suchen und den Bereich in Ihre system.xml um die Zeile 600 hinzufügen Symlinks mit doppelter Prüfung sind weiterhin mit aktiviert

n98-magerun.phar config: dump | grep symlink

Hier ist die Diff-Datei für magento1933 und magento1932, um Änderungen am Standarddesign zu identifizieren, die sich auf Ihre benutzerdefinierten / erweiterten Designs auswirken können.

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


Warum haben sie die Symlinks-Option entfernt? Gibt es jetzt einen Exploit, der für die Öffentlichkeit zugänglich ist (außerhalb des Administrators), oder besteht nur ein Risiko, wenn er sich in einer gemeinsam genutzten Umgebung befindet?
PaddyD

Dieser Thread scheint meine Frage zu beantworten: magento.stackexchange.com/questions/176952/…
PaddyD

Symlinks sind aus einem bestimmten Grund deaktiviert. Ich schlage vor, anstelle von Symlink zu kopieren: magento.stackexchange.com/a/177149/54863
Barryvdh

9

Problem: Die Verwendung von php7 löst manchmal den folgenden Fehler aus:

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}

Es ist ziemlich sicher, dass die Zend-Version etwas damit zu tun hat. Eine schnelle Lösung ist dies, ist aber mit Sicherheit nicht korrekt:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 ersetze es durch:

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

-> und app / code / core / Enterprise / PageCache / Model / Observer.php: 177 mit:

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

Natürlich erstellen Sie ein Addon, um dies neu zu schreiben. Aber ich bin mir sicher, dass es hier etwas Besseres gibt.

UPDATE (bessere Lösung)

-> Gehen Sie zu: lib / Zend / Json.php und fügen Sie nach der Zeile 76 Folgendes hinzu:

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

Erstellen Sie Ihre Erweiterung, um sie zu überschreiben, und bearbeiten Sie die Kerndatei nicht.


Cache wurde komplett geleert. Dies ist nicht das gleiche Problem.
folektoras133

2
Wir sind auf dasselbe Problem gestoßen - das Zurücksetzen von app / code / core / Enterprise / PageCache / Model / Observer.php hat das Problem behoben, aber offensichtlich ist dies nicht die richtige Lösung, sondern nur die Vorbeugung 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: Dynamischer Code oder CSS deaktivieren das Formulareingabeelement beim Auschecken

Ein Problem, das ich gesehen habe, ist, dass dynamischer Code (paypal plus) beim Auschecken auf einer Seite das fieldset- Element im Ein-Schritt-Zahlungsmethode-Formular html überschreibt - Löschen oder Deaktivieren (mit CSS) des ausgeblendeten form_key-Elements.

Die Lösung ist das , um sicherzustellen , formkey Element nicht wird deaktiviert durch eine dynamische Code oder CSS. Das Verschieben des Formkey-Codes außerhalb des fieldset- Elements kann ebenfalls hilfreich sein

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

Sie können leicht überprüfen, ob der form_key erkannt und an den One-Page-Controller gesendet wird, indem Sie die Ajax-Netzwerkanforderungen in Ihrem Browser untersuchen, während Sie die Checkout-Methoden durchlaufen. Jede Methode sollte den Formularschlüssel in den Ajax-Formulardaten enthalten, sofern das Formular vorhanden ist Der Schlüssel ist nicht vorhanden, aber der Magento-Quellcode wurde gepatcht. Überprüfen Sie, ob externer Code das Schlüsselelement des Formulars beeinflusst, z. B. CSS oder dynamische clientseitige Änderungen.

Bildbeschreibung hier eingeben


2
Dieses Problem schien bei mir mit EE nicht zu funktionieren. Ich stellte fest, dass die Datei ebenfalls app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml aktualisiert werden musste: Zeilen 35-38 müssen aktualisiert werden, um sie || elements[i].name == 'form_key'zusammen mit den anderen Selektoren einzuschließen, damit das Formularfeld form_key deaktiviert bleibt.
Greg Nickoloff

Danke g-man1066! Das war genau das Problem, das ich hatte.
Grafikchaos


8

PROBLEM: Die Kundenregistrierung schlägt fehl, wenn die allgemeine 5-Stufen-Kaufabwicklung von Magento verwendet wird.

Dieses Problem tritt nur auf, wenn wir die Formularschlüsselauthentifizierung aktivieren. Verwendete Version: 1.7.0.2, aber es sieht so aus, als hätte jemand das gleiche Problem auch in Version 1.9.3 veröffentlicht. SUPEE-9767 Patch / CE 1.9.3.3 - One Page Checkout - Problem bei der Kundenregistrierung

Wenn Sie zur Kasse gehen, haben Sie zwei Möglichkeiten: AUSKASSE ALS GAST ODER REGISTRIERUNG Sobald Sie auf "Registrieren" geklickt und das Formular mit dem Passwort ausgefüllt haben, fahren Sie mit allen Schritten fort und schließen die Bestellung ab. Die Bestellung wird aufgegeben, ABER der Kunde wird nie in Magento registriert. Es sieht so aus, als hätte der Gast eine Bestellung aufgegeben.

Als ich zurück und ging Behinderte Form - Key - Authentifizierung und versuchten Auftrag vergeben , während als Kunde registriert, wurde es ohne Probleme gestellt und der Kunde im Backend registriert wurde.


1
Hier ist ein ausführlicherer Beitrag zu diesem Thema: magento.stackexchange.com/questions/177035/…
Raphael bei Digital Pianism

8

UPDATE 13/07/2017 [DIE AUSGABE IST BEHOBEN]

Das Magento-Team hat SUPEE-9767 V2 in dieser Version des Patches veröffentlicht. Das Problem mit transparenten GIFs und PNGs wurde behoben.

Sie sollten alle Änderungen an der Datei, die in diesem Thread beschrieben wurde, rückgängig machen. Setzen Sie dann den angewendeten V1-Patch zurück und wenden Sie schließlich die neue Version V2 an.


PRE - SUPEE-9767 V2

Bitte verwenden Sie nicht den unten beschriebenen Code, sondern installieren Sie V2 des Patches. Das unten beschriebene Problem wurde bereits in dieser Version behoben

Wenn jemand Probleme mit transparenten PNGs hat, wird der Hintergrund beim Hochladen aus dem Admin-Bereich schwarz. (Auf den Produkten) ist in Bezug auf das Bild Upload Rückruf eingeführt in:

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

Im Moment bin ich mir nicht sicher, was genau dieses Verhalten verursacht, aber ich versuche es herauszufinden. Ich kann bestätigen, dass das seltsame Verhalten verschwindet, wenn der Rückruf entfernt wird.

Bildbeschreibung hier eingeben

AKTUALISIEREN

Ok, ich habe festgestellt, dass die Funktion, die ebenfalls von SUPEE-9767 aktualisiert wurde, tatsächlich die Transparenz in der PNG bricht. Eine Kopie des Originalbildes wird ohne Transparenz erstellt.

+++ 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.'));

AKTUALISIEREN

Hier ist eine aktualisierte Version der Funktion, um die PNG-Transparenz zu erhalten

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

Diese beiden Zeilen müssen zum Patch hinzugefügt werden. Aktualisieren Sie die Funktion inapp/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.'));
}

UPDATE 23/06/17

Diese aktualisierte Version der Funktion behebt die PNG- und die GIF-Transparenz.

    /**
 * 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.'));
}

1
Dies löste mein Problem in einer Magento 1.7 Installation. Vielen Dank!
Tjitse

Kein Problem. Notieren Sie sich diese Änderung, falls das Magento-Team den Patch nicht repariert. Sie müssen ihn zurücksetzen, wenn Sie den nächsten Patch ausführen. Ich habe das Problem an die Community unter bugcrowd.com weitergeleitet und hoffe, dass sie bald Patch Fix einführen werden.
Daniel Yovchev

Dies behebt es für PNGs, aber nicht für transparente GIF-Dateien. gif-dateien müssen mit imagecolortransparent etwas anders behandelt werden
alternate

Vielen Dank für den Hinweis auf alternize, siehe die aktualisierte Funktion, die auch die GIF-Transparenz behebt.
Daniel Yovchev

7

Problem: Symlink-Benachrichtigung für Administratoren nicht zulassen

Die Symlink-Benachrichtigung wird nicht im Administrator-Benachrichtigungsbereich angezeigt, da sie nicht in der Liste enthalten ist <block type="core/text_list" name="notifications" as="notifications">

Der Patch für CE und EE unten:

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

Das Problem befindet </block>sich am Ende von checkout_formkey(was sich selbst beendet) und schließt daher das übergeordnete Element notifications. Dies führt dazu, dass das notification_symlinknicht in das aufgenommen core/text_listund nicht gerendert wird.


Dies ist kein wirkliches Problem. Die Benachrichtigung wurde entfernt, da Symlinks explizit deaktiviert und der Symlink-Konfigurationsabschnitt entfernt wurden. Es ist nicht möglich, den Symlink-Wert in admin in Version 1933 manuell zu ändern. Daher ist es ziemlich sinnlos, eine Administratorbenachrichtigung anzuzeigen. Das Problem wird bei neuen Installationen von 1933 auftreten, bei denen Benutzer, die Symlinks benötigen, z. B. für Modman, diese nicht mehr manuell aktivieren können. Man könnte daraus schließen, dass Magento keine neuen 1.x-Installationen erwartet ...
paj

Ich bin anderer Meinung, dieser Patch deaktiviert die Konfiguration nicht explizit, wenn sie bereits festgelegt ist - er deaktiviert sie nur, wenn sie noch nicht festgelegt ist. Wenn für eine Instanz dev / template / allow_symlink in der Datei DB / local.xml vor diesem Patch auf yes festgelegt wurde und sie den Patch anwenden, SOLLTEN sie die Warnung erhalten, dass Symlinks zulässig sind, da sie potenziell anfällig sind.
Mwylde

Ich verstehe deinen Standpunkt und du hast recht. Aber für einen normalen Benutzer, was würden sie dann tun - es ist unmöglich, es manuell von admin zu deaktivieren, da die Konfigurationsoption entfernt wurde. Es ist ein bisschen wie ein Haken 22 Situation ...
paj

7

Kleiner Tipp für #patchday; Führen Sie nach dem Kopieren von 1.9.3.3 über Ihre Installation den Befehl aus, um git diff -w --stat | grep -v " 2 +" | grep -v " 0"größere Änderungen an Dateien schnell zu erkennen.


7

Problem: EE-Versandvorlage nicht gepatcht

Ich habe eine EE 1.13.1.0-Installation gepatcht, und in der Enterprise-Versandvorlage ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) wurde der Formularschlüssel nicht hinzugefügt, in der Abrechnungs- und Zahlungsvorlage jedoch.

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


Ich musste auch (für EE 1.14.2) den form_key hinzufügen /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtml,.../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml
Greg Nickoloff

4

Es gibt ein Problem mit Magento EE-Versionen, die mit SUPEE-9767 gepatcht sind (also nicht mit Upgrades auf 1.14.3.3). Der Formularschlüssel auf dieser Seite wird zwischengespeichert. Wenn ich also meinen Cache leeren und dann eine Produktseite aufrufen und sicherstellen, dass die Seite vollständig zwischengespeichert ist (mehrmals aktualisieren), sollte ich dieses Produkt in meinen Warenkorb legen können.

Wenn ich jetzt einen anderen Browser (oder Inkognito-Modus) öffne, öffne dieselbe Seite und versuche, das Produkt erneut in den Warenkorb zu legen. Das Produkt wird aufgrund des Formularschlüssels nicht in den Warenkorb gelegt. Wenn Sie nun den Cache erneut leeren, kann das Produkt erneut in den Warenkorb gelegt werden.

Vielen Dank an Jasper Zeinstra


3

Für Entwickler, die Magento Composer Intaller verwenden, können Sie die Bereitstellungsstrategie in "Kopieren" anstatt in "Symlink" ändern. Sie können auch konfigurieren, dass die Moduldateien an Ihren .gitignore angehängt werden, damit Ihr Repository sauber bleibt.

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


Wir fanden heraus, dass mit Kopie "magento-force": true,wichtig wird
Jeroen


2

Problem: Patch arbeitete an Vanille Magento 1.7.0.0 [bearbeitet]

Beim Testen unseres Patch-Skripts haben wir ein Problem im Patch für Magento 1.7.0.0 entdeckt. Ich weiß nicht, ob es noch von irgendjemandem verwendet wird, aber es ist trotzdem ein Problem in SUPEE-9767. Wir haben eine Vanille-Installation verwendet und zuerst alle vorherigen Patches installiert.

Verwendete Patch-Datei: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh Die Patch-Datei funktioniert für Magento 1.7.0.1 und 1.7.0.2

Zusammenfassung der Probleme:

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

Für das Protokoll haben wir den Patch am 1.7.0.0 ausprobiert:

$ 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

4
Wenn Sie diese Datei vermissen, haben Sie höchstwahrscheinlich den Sicherheitspatch SUPEE-7405 nicht installiert.
Ryan Hoerr

@ RyanHoerr Sie haben Recht, SUPEE-7405 wurde übersprungen, weil die offizielle Datei PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.shfür 1.7.0.0 nicht funktioniert. Ich habe eine feste Version der Datei erstellt. Wenn jemand es braucht, sende mir eine Nachricht.
Jeroen Vermeulen - MageHost

2

Ich musste diesen Patch nur wegen eines seltsamen Verhaltens zurücksetzen. Aus irgendeinem Grund konnten bestimmte Benutzer bestimmte Artikel nicht in ihren Warenkorb legen.

Ich gehe davon aus, dass es etwas mit alten Anführungszeichen zu tun hat, die mit dem aktuellen Anführungszeichen für diesen Kunden kollidieren. Ich habe dieses Problem überprüft, indem ich mich als Benutzer angemeldet habe, um sicherzustellen, dass es nicht nur ein 1D10T ist.

Es ist ein Problem, seit ich diesen Patch letzten Freitag genommen habe. Wir verwenden 1.14.2.4 . Wir sind stark modifiziert, so dass es für andere Benutzer gut funktionieren kann. Nur eine Warnung!


Das ist richtig, der Patch bricht ab, wenn Sie eine EE-Version von Magento verwenden. Grundsätzlich tritt das Problem auf, wenn das PageCache-Modul eine Version der form_key-Generierungslogik hat, während die Sitzung eine eigene hat. Wenn FPC die zwischengespeicherte Version der angeforderten Seite hat, aber Minicart neu generieren muss, wird eine Sitzung ausgelöst, die form_key neu generiert, während FPC save aufgerufen wird, wodurch sein eigener form_key generiert wird. Zu diesem Zeitpunkt unterscheidet sich der Sitzungswert von form_key von einem im Kundencookie (im FPC-Prozessor verwendet) gespeicherten Wert, sodass beim Hinzufügen zum Warenkorb-Controller ein ungültiger Schlüssel angezeigt wird.
Stjepan

Ich stoße auch auf dieses Problem. Ich melde mich, wenn ich eine Lösung finde.
Cmtickle

Ich habe dieses Problem behoben, Erklärung hier: magento.stackexchange.com/questions/177942/…
cmtickle

Weiß jemand, ob dies in SUPEE-9767 v2 behoben ist?
Schüler von einem

2

Problem : Endlose Umleitungsschleife auf 1.6.0.0

Schnelle Lösung

Finden Sie die folgenden Zeilen in der methodengeschützten Funktion _checkBaseUrl ($ request) in der Datei 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
 ) {  

Ändern Sie diese Zeilen in

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

Speichern Sie danach die Datei (speichern Sie sie in Ihrem REPO), löschen Sie den Cache (entfernen Sie alles im Ordner var / cache) und laden Sie Ihr Store-Front neu. Nach der Installation des SUPEE 9767-Patches sollten die Site-Ladevorgänge ohne weitere 302 Weiterleitungsprobleme angezeigt werden.

Ursache

Die Differenz im SCHEME-Wert zwischen der tatsächlichen Anforderung und dem URI nach der Umleitung. Beispiel: Die tatsächliche Anforderung gibt das Schema HTTP zurück, das Schema in der URI kann jedoch HTTPS sein.

Mögliche Gründe

  1. Möglicherweise haben Sie eine Umleitungsregel in der .htaccess-Datei, um alle http-Anforderungen an https umzuleiten. Der Benutzer fordert http://IhreDomain.com an, und Sie haben möglicherweise das Schema geändert und ihn an https: //IhreDomain anstelle von http://IhreDomain.com weitergeleitet, die er tatsächlich angefordert hat.

  2. Sowohl die sicheren als auch die unsicheren Basis-URLs beginnen mit https


2

Der BESTÄTIGTE BUG "Kundenregistrierung schlägt beim Checkout fehl" ist auf meiner Seite etwas anders aufgetreten.

Wenn der Kunde sich beim Checkout registrieren wählt, wird sein Passwort nicht korrekt gespeichert. Der Kunde wird korrekt angelegt, nur dass das Passwort nicht gespeichert wird. Ich erkannte dies daran, dass das Passwort in der Begrüßungs-E-Mail nicht angezeigt wurde. Leute können sich deswegen auch nicht einloggen.

Fehlerbehebung in SUPEE-9767 Patch / CE 1.9.3.3 - One Page Checkout - Das Problem mit der Kundenregistrierung hat auch für mich funktioniert .


2

Kann mir jemand sagen, wofür das in supee-9767 ist?

Bildbeschreibung hier eingeben


1
Die jQuery 1.10.2-Version gilt als anfällig und wird von einigen PCI-Scannern als fehlerhaft eingestuft. Die 1.12 Version ist nicht.
Ryan Hoerr

@Detzler StackExchange ist kein Forum. Wenn Sie eine Frage stellen möchten, sollten Sie eine posten, keine Antwort auf eine Frage.
Toon81

1
Ryan Hoerr erkundigte sich nach Problemen, die der Patch mit sich brachte. Also sagte ich ihm eine mögliche Änderung, wie Sie auf dem Screenshot sehen. Ich kann den Grund für diese Änderung nicht erklären. Also fragte ich sub. Also, was ist dein Problem?
Detzler

2

Der Patch funktioniert nicht einmal für ein Vanille-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

auch nach manuellem Anwenden älterer Patches.

$ 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

Die Lösung / das Problem, das ich gefunden habe, ist, dass einige der Änderungen im Patch für 1.7.0.2 für Dateien gelten, die vor 1.9.2.3 nicht existieren. Deshalb habe ich die folgenden Dateien von einer brandneuen 1.9.2.3-Installation kopiert, bevor ich das Patch-Skript ausgeführt habe:

  • app / code / core / Mage / Core / Modell / Datei / Validator / Image.php
  • app / code / core / Magier / Verkauf / Modell / Angebot / Item.php

Der Patch setzt voraus, dass alle anderen Sicherheitspatches bereits angewendet wurden. Die Dateien, von denen Sie sprechen, wurden durch vorherige Patches hinzugefügt / geändert. Sie vermissen mindestens SUPEE-7405.
Ryan Hoerr

Hallo Ryan, Tatsächlich habe ich versucht, 7405 auch anzuwenden, aber auch nicht funktioniert ... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52 \ (1) .sh Prüft, ob Patch erfolgreich angewendet / zurückgesetzt werden kann ... FEHLER: Patch kann nicht erfolgreich angewendet / zurückgesetzt werden. (..) Adminhtml / Helper / Sales.php Hunk # 1 FEHLGESCHLAGEN bei 121. 1 von 1 Hunk FEHLGESCHLAGEN - Speichern von Ablehnungen in Datei (..) Adminhtml / Helper / Sales.php.rej Patchen von Datei (..) / Core / Model / Config.php Hunk # 1 FEHLGESCHLAGEN bei 1642. 1 von 1 Hunk FEHLGESCHLAGEN - Speichern von Ablehnungen in die Datei (..) Config.php.rej Patching-Datei (..) / Quote / Item.php Hunk # 1 FEHLGESCHLAGEN um 509 ....
Ricardo Martins

@RicardoMartins wie kann ich diesen Fehler beheben: Patchen der Datei app / locale / de_DE / Mage_Adminhtml.csv Hunk # 2 FEHLGESCHLAGEN bei 36. 1 von 2 Hunks FEHLGESCHLAGEN - Speichern von Ablehnungen in der Datei app / locale / de_DE / Mage_Adminhtml.csv.rej ?
Zus

0

Fügen Sie https://magento.stackexchange.com/a/176930/46249 hinzu

Beachten Sie, dass Symlinks in neuen Magento-Installationen standardmäßig immer deaktiviert waren. Die Konfigurationswerte für admin YES / NO lauten standardmäßig 'NO'. Das Update deaktiviert jetzt ausdrücklich Symlinks in config.xml und entfernt vorsichtshalber auch den Vorlagenbereich von admin-> developer, der die Konfigurationsoption enthielt.

Dies hat keine Auswirkungen auf Ihre aktuellen Symlink-Einstellungen. Wenn Sie Symlinks vor 1.9.3.2 manuell aktiviert haben, bleiben sie aktiviert, obwohl Sie die Einstellung in admin nicht mehr sehen können.


Der fett gedruckte Text ist nicht korrekt. Wenn ein Update auf 1.9.3.4 (SUPEE-9767 V2) oder neuere aktuelle Einstellungen gelöscht werden:

# 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'
    ))
);

Verantwortliche Administratoren können den Symlink-Admin-Bereich wieder aktivieren, indem sie nach den unterschiedlichen Änderungen im Vorlagenbereich in app / code / core / Mage / Core / etc / system.xml suchen und den Bereich in Ihre system.xml um die Zeile 600 hinzufügen Symlinks mit doppelter Prüfung sind weiterhin mit aktiviert

Nur die Option config wieder sichtbar machen, löst das Problem nicht. Die Option wird angezeigt, aber Sie können die Konfiguration nicht ändern, da das neu eingeführte Backend-Modell das Speichern des Werts verhindert. Sehen:

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

und

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

Sie müssen dieses Backend-Modell also entfernen oder überschreiben. Weitere Informationen finden Sie unter Aktivieren von Symlinks nach der Installation von SUPEE-9767 V2.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.