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.

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:

• Von Peter O'Collaghan: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/
• Von Max Chadwick: https://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

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.

• Kundenregistrierung schlägt an der Kasse fehl BESTÄTIGT & FIXIERT IN V2
• PHP7 und EE Fehler BESTÄTIGT
• Fehler mit EE, FPC und Design Exceptions BESTÄTIGT
• In den Warenkorb und Cookie-Fehler in EE BESTÄTIGT
• Multishipping nach Patch BESTÄTIGT unterbrochen
• Fehlende Fehlerbehebung inhead-simple.phtml BESTÄTIGT & BEHOBEN IN V2
• In 1.9.2 CONFIRMED & FIXED IN V2 wird keine Admin-Symlink-Warnung angezeigt
• Wasserzeichen erhalten einen schwarzen Hintergrund, wenn sie transparent BESTÄTIGT UND IN V2 FESTGELEGT sind
• Upgrade über Magento Connect nicht möglich
• Endlose Umleitungsschleife auf 1.6.0.0

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.

• Patch-Datei app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FEHLGESCHLAGEN bei 36.
• Patch-Datei App / Design / Frontend / Enterprise / Standard / Vorlage / Persistent / Checkout / Onepage / billing.phtml Hunk # 1 bei 225 fehlgeschlagen.
• Patch-Datei App / Code / Core / Enterprise / PageCache / Model / Observer.php Hunk # 6 um 1093 fehlgeschlagen.
• Patch-Datei app / code / core / Mage / Core / etc / system.xml Hunk # 3 um 1355 FEHLGESCHLAGEN.
• Patch-Datei App / Code / Core / Magier / Vertrieb / Modell / Angebot / Item.php Hunk # 1 bei 500 gescheitert.
• Hunk schlug am 1.8.0.0 fehl

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/

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

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

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

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.

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.

Problem: Fehlende Fixes in head-simple.phtml

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

brauche die gleichen Updates wie

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

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.

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.

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

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.

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.

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.

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

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

Ich hatte ein Problem mit EE 1.14.2.2 mit aktiviertem FPC und diesem Patch.

Benutzer konnten zeitweise keine Artikel in den Warenkorb legen.

Erklärung und Fehlerbehebung hier: SUPEE-9767-Problem: In den Warenkorb Problem, Enterprise Full Page Cache

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

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!

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

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 .

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

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

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.