Patch di sicurezza SUPEE-8788 - Possibili problemi?

L'ultima patch di sicurezza Magento 1 SUPEE-8788 contiene 17 aggiornamenti APPSEC , quindi è molto importante applicarla il prima possibile. D'altra parte, ci sono molte potenziali interruzioni di compatibilità con le versioni precedenti e, data la cronologia delle patch nell'ultimo anno, non la applicherei con noncuranza.

La cosa buona è che questa volta non ci sono modelli di frontend coinvolti, quindi sembra che non abbiamo bisogno di patchare tutti i nostri temi. Questo è vero solo per Magento 1.8 o versioni successive.

Tuttavia: hai riscontrato problemi di compatibilità o bug dopo aver applicato la patch?

Note importanti

Si noti che 1.9.3 è diverso da 1.9.2.4 + SUPEE-8788. Ecco la differenza tra i due: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Aggiornamento del 14 ottobre: ​​è stata rilasciata la v2 della patch (vedi sotto) A partire dal 13 ottobre, le patch da 1.5.xa 1.8.x sono state rimosse dal sito Web Magento a causa dell'incompatibilità con le patch precedenti (vedere sotto):

https://community.magento.com/t5/Security-Patches/SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error/td-p/50434/highlight/false/page/2

V3 della patch

Questa nuova versione è solo per Magento EE 1.13.0.x

Applica il V3:

• ripristina SUPEE 1533 (se installato)
• installa SUPEE 3941 (se non installato)
• installa SUPEE 8788 v3

V2 della patch

Applica il V2:

• ripristina SUPEE 8788 v1
• ripristina SUPEE 1533 (se installato)
• installa SUPEE 3941 (se non installato)
• installa SUPEE 8788 v2

DemacMedia ha sviluppato un utile script bash per automatizzare il processo sopra, puoi trovarlo qui: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Dettagli della patch

Dopo aver scavato nella patch ecco le parti interessanti (patch da 1.9.2.4):

• Mage_Adminhtml_Block_Media_Uploaderè stato sostituito con Mage_Uploader_Block_Multiplequindi c'è un Mage_Uploadermodulo completo che elimina il supporto Flash . Il vecchio blocco è ora obsoleto ed estende il nuovo blocco.
• Sempre per quanto riguarda l'uploader, il Mage_Downloadablemodulo è stato refactored per gestire il nuovo uploader non flash. Utilizza Mage_Uploader_Block_Singlecome blocco di caricamento invece di utilizzare i modelli.
• A seguito di tale modifica, t egli file SWF skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swfe skin/adminhtml/default/default/media/uploaderSingle.swfsono stati eliminati.
• Il controller di eliminazione dell'indirizzo è ora protetto con la chiave del modulo direttamente tramite il getDeleteUrldaMage_Customer_Block_Address_Book
• Il controller di rimozione degli elementi della lista dei desideri è ora protetto con la chiave del modulo tramite il getRemoveUrldaMage_Wishlist_Helper_Data
• Il metodo di pagamento Paypal Express ora assicura che l'e-mail del cliente utilizzata esista in Magento al momento del check out e della registrazione di un nuovo utente. (capire: il nuovo utente viene creato prima dell'elaborazione del nuovo preventivo)
• I metodi di pagamento che utilizzano il client cURL / HTTP ora sono stati CURLOPT_SSL_VERIFYHOSTimpostati su 2 (era 0 prima) e il CURLOPT_SSL_VERIFYPEERflag viene ora aggiunto alle chiamate cURL. Il flag Verifica peer può essere abilitato / disabilitato tramite la configurazione del metodo di pagamento tramite il menu a discesa Abilita verifica SSL.
• Mage_Http_Client_Curlora è CURLOPT_SSL_VERIFYPEERimpostato su true (era falso prima) , attenzione se si dispone di un modulo personalizzato che lo utilizza.
• Le dimensioni massime per le immagini dei prodotti sono ora configurabili nella configurazione. NB: può caricare un messaggio di errore divertente se carichi immagini troppo grandi: formato file non consentito in Magento 1.9.2.2 dopo il caricamento della patch

Problemi noti di SUPEE-8788 v2

• Magento 1.9.2.0 SUPEE-8788 v2 Hunk # 1 NON RIUSCITO a 91 dopo il ripristino di SUPEE-1533
• La patch non può essere applicata sul modello PayPal Express: Magento 1.9.2.2 SUPEE-8788 v2 Hunk # 1 FAILED
• Coincidenza non correlata alla patch Le email hanno smesso di essere inviate su 1.8: https://magento.stackexchange.com/q/141799/2380 e problema con la patch di sicurezza 8788 V2
• Modifica incompatibile all'indietro quando si chiama il getConfig()metodo dal blocco uploader: Problema nel Pannello di amministrazione dopo l'installazione della patch 8788 di SUPEE

Problemi noti di SUPEE-8788 v1

• Aggiornamento: il v2 della patch risolve quel problema (vedi sopra)Conflitto tra SUPEE-1533 e SUPEE-8788 , possibile soluzione (hacky) qui . Una soluzione meno caotica qui
• Aggiornamento: v2 della patch risolve quel problema Unsupported data type Nerrore in /lib/Unserialize/Reader/ArrValue.php1.9.1.0 e possibilmente versioni precedenti quando viene applicata la patch. risolto qui: https://gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
• Aggiornamento: il v2 della patch risolve quel problema Possibile conflitto con SUPEE-3941: https://magento.stackexchange.com/a/140696/2380
• Problema con OS X:Illegal Byte Sequence : SUPEE-8788 su OSX - sequenza di byte illegale
• Patch malformata (probabilmente dovuta alla sequenza binaria nella patch) : patch Magento 1.9.2.4 SUPEE-8788 patch deformata alla linea 5790
• Inclusione di un test_oauth.phpfile con patch EE , non inviare quel file a prod
• Possibile problema di accesso su EE relativo aEnterprise_Pci : https://magento.stackexchange.com/a/140577/2380
• Problema se si modifica il file patch in quanto contiene file binari incapsulati , utilizzare questo metodo se è necessario modificare: https://magento.stackexchange.com/a/140575/2380
• Se hai una app/code/localversione di Mage/Core/functions.php, avrai problemi con la nuova hash_equalsfunzione : https://magento.stackexchange.com/a/140664/2380
• Buono a sapersi che sono in corso alcune modifiche ai template per quanto riguarda form_key per Magento prima della 1.8
• Possibile problema su 1.5.1.0 con downloader/Maged/View.php: Patch di sicurezza SUPEE-8788 non riuscita in downloader / Maged / View.php (M1 v1.5.1.0)
• Nel caso in cui hai rimosso / rinominato la downloadercartella: https://magento.stackexchange.com/a/140631/2380

Problemi noti 1.9.3.0

Modifica: poiché l'elenco si sta allungando ed è praticamente fuori tema in questa risposta (in quanto non relativo a SUPEE-8788) puoi fare riferimento a questo post per l'elenco dei problemi noti 1.9.3.0: https: //magento.stackexchange. COM / a / 140826/2380

Quando si applica la patch questo errore può verificarsi:

checking file skin/adminhtml/default/default/media/flex.swf
checking file skin/adminhtml/default/default/media/uploader.swf
checking file skin/adminhtml/default/default/media/uploaderSingle.swf
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
checking file skin/adminhtml/default/default/xmlconnect/boxes.css

La patch 8788 contiene contenuto binario. Poiché Magento non fornisce alcun collegamento per il download diretto (odio questa politica da allora), devi scaricare la patch sul tuo computer e caricarla con un'applicazione di trasferimento file (come WinSCP su Windows) sul tuo server. WinSCP, ad esempio, verrà caricato in modalità TESTO (WinSCP gestisce i file * .sh come testo per impostazione predefinita).

Quindi la soluzione alternativa è quella di comprimere / tarare il file patch e decomprimere / decomprimere nuovamente sul server. et voilà.

Mi dispiace non ho avuto modo di rispondere a questa domanda

1. Scarica la versione corretta di magento (ad esempio: CE 1.9.1.0)
2. Sostituisci i seguenti file con il percorso scaricato

skin / adminhtml / default / default / media / flex.swf skin / adminhtml / default / default / media / uploader.swf skin / adminhtml / default / default / media / uploaderSingle.swf

3. Esegui la patch

Ha funzionato per me

Se hai precedentemente applicato SUPEE-1533, la patch non funzionerà app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

Ho risolto questo da ...

1. Ripristina manualmente le modifiche introdotte a quel file da SUPEE-1533
2. Applicare SUPEE-8788
3. Reintrodurre manualmente le modifiche introdotte in quel file da SUPEE-1533

La rimozione della modifica da SUPEE-8788 è pericolosa perché il file patch contiene dati binari e il salvataggio in un editor può causare problemi (un altro problema).

Ecco un riassunto di ciò che io (e altri) abbiamo riscontrato finora, sto cercando di mantenerlo ordinato, sentiti libero di aggiungere o collegare tutto ciò che manca, il post è un Wiki della comunità:

Motivi della patch non riuscita

Se viene visualizzato il messaggio "ERRORE: impossibile applicare / ripristinare la patch", cercare "Hunk # 1 FAILED" nei messaggi di registro per verificare a quale file non è riuscita la patch.

• Apparentemente v2 della patch per Magento 1.7 si aspetta che SUPEE-3941 sia presente anche se esiste solo per Magento 1.8 e 1.9 . Se sei su Magento 1.7 e vedi errori relativi ai file in downloader, scarica SUPEE-3941 per 1.8 e applicalo su 1.7, dovrebbe funzionare. Vedere il thread dei commenti qui: problema della patch di sicurezza SUPEE 8788

• Sulle versioni di Magento a cui è stato applicato SUPEE-1533 in precedenza, la patch non funziona app/code/core/Mage/Adminhtml/controllers/DashboardController.phpperché il file è interessato da entrambe le patch e SUPEE-8788 (in modo errato!) Presuppone che sia presente la versione senza patch. Questo è ancora vero con la versione 2 della patch! La versione 2 include le modifiche da SUPEE-1533, quindi se è stato installato in precedenza, è necessario ripristinarlo, ma non è necessario applicarlo nuovamente in seguito.

• Se hai eliminato o rinominato la directory "downloader", la patch fallirà perché corregge un file all'interno del downloader. La soluzione più semplice è ripristinare la directory del downloader originale, applicare la patch, quindi eliminare nuovamente la directory. In alternativa, puoi anche rimuovere le istruzioni per downloader/lib/Mage/HTTP/Client/Curl.phpdalla patch.

• Altri messaggi "Hunk FAILED" sono generalmente dovuti a cambiamenti nei file core o mancate patch precedenti. Assicurati che tutte le patch precedenti per la tua versione di Magento siano installate e non hai apportato modifiche ai file core.

• Un altro problema comune è che la patch non riesce a eliminare i .swffile a causa del loro contenuto binario. L'errore sarà simile al seguente:

  checking file skin/adminhtml/default/default/media/uploaderSingle.swf
  Reversed (or previously applied) patch detected!  Assume -R? [n]
  Apply anyway? [n]
  Skipping patch.
  1 out of 1 hunk ignored
  

  o così

  Patching file skin/adminhtml/default/default/media/uploader.swf using Plan A...
  No such line 2 in input file, ignoring
  Empty context always matches.
  Hunk #1 failed at 0.
  1 out of 1 hunks failed while patching skin/adminhtml/default/default/media/uploader.swf
  Hmm...  The next patch looks like a unified diff to me...
  The text leading up to this was:
  --------------------------
  

  o in questo modo:

  Checking if patch can be applied/reverted successfully...
  /bin/patch: **** malformed patch at line 5790: ?rM]M??????&X㔮??v??Q;r?N?qJ??Y???I0?Y??4??'?????9?.??X?Ǒ?{??ax!G???I???q?u|????թ??????|
                                                 h??o?V@??|? ?g?H aꪭ??Ю???,I"?ğ????.??    yI?I\????)?X?
                       ?p???*?e?q?K8<DqD?H;|?
  ERROR: Patch can't be applied/reverted successfully.
  

  Le possibili soluzioni sono fornite in questa risposta da @infabo. Scaricare la patch direttamente sul sistema in cui voglio applicarla, usando l'arricciatura come spiegato in https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e ha sempre funzionato per me, tranne quando l'ho provato su Cygwin

Modo avanzato per gestire le patch non riuscite: @PeterOCallaghan ha suggerito di commentare la linea a secco e gestire manualmente i file * .rej. In questo modo la patch può essere parzialmente applicata e se non riesce a eliminare i file swf, è possibile farlo manualmente. O se non riesce ad aggiornare i file downloaderperché hai eliminato quella directory, puoi semplicemente ignorarlo.

1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh(o un nome file simile) cambia _apply_revert_patch dry-runin modo che appaia #_apply_revert_patch dry-run

2. eseguire la patch emettendo ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

Quello patch i tuoi file

3. Commenta _apply_revert_patcha#_apply_revert_patch

4. eseguire nuovamente la patch per aggiungere la app/etc/app/etc/applied.patches.listvoce

5. grep per tutti i file .rej con

   git status | grep *.rej

6. lavorare manualmente in quei cambiamenti

Problemi dopo l'applicazione della patch

Chiavi del modulo

• Per le versioni Magento precedenti alla 1.8 ci sono cambiamenti nei frontend/base/defaulttemplate. Assicurati di applicare manualmente le stesse modifiche al tema se sovrascrive questi file

  Più specificamente, è stata aggiunta una chiave del modulo per azioni frontend come:

  • Rimozione di un elemento dalla lista dei desideri
  • Eliminazione dell'indirizzo di un cliente dalla vista del negozio
  • Aggiornamento di un articolo preventivo nel carrello

  Vedi questa risposta di @LukeRogers se riscontri problemi con queste azioni.

Uploader personalizzato

Unirgy_Rapidflow e altre estensioni con moduli di caricamento personalizzati non funzionano più.

Guarda questa risposta di @mpchadwick e commenta di @lloiacono

L'ho risolto sostituendo $this->getUploader()->getConfig()con $this->getUploader()->getUploaderConfig()inUnirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

Per scoprire se una delle tue estensioni lo utilizza, puoi eseguire quanto segue sulla riga di comando:

grep -R 'getUploader()->getConfig();' app/code/community

Messaggi di errore riportati

• Errore irreversibile PHP: chiamata alla funzione indefinita hash_equals ()

  succede se siete su una versione di PHP prima di 5.6 e sovrascrivere code/core/Mage/core/functions.phpin code/local/Mage/core/functions.php(che potrebbe essere il caso se si utilizza le estensioni Fishpig). Vedi questa risposta di @ClaudiuCreanga

Problemi risolti nella v2 della patch

Se riscontri uno di questi problemi, probabilmente usi la versione 1 della patch ("v1" nel nome del file). Scarica di nuovo la patch per ottenere "v2" che risolve questi problemi:

• Si è verificato un problema di compatibilità con SUPEE-3941 e downloader/lib/Mage/HTTP/Client/Curl.php

• 'Eccezione' con il messaggio 'Tipo di dati non supportato N' in /lib/Unserialize/Reader/ArrValue.php

• La patch per EE 1.14.2.0 conteneva accidentalmente un nuovo file test_oauth.php che dovresti eliminare! Vedi questa risposta di @MatthiasZeis

Se ottieni

Call to undefined function hash_equals() error

anche se la tua patch ha avuto successo, allora può significare che hai copiato funzioni.php app/code/local/Mage/Core.

Dovrai inserire anche quella funzione perché quel file sovrascrive quello principale.

Quindi inserire app/code/local/Mage/Core/functions.phpalla fine:

if (!function_exists('hash_equals')) {
    /**
     * Compares two strings using the same time whether they're equal or not.
     * A difference in length will leak
     *
     * @param string $known_string
     * @param string $user_string
     * @return boolean Returns true when the two strings are equal, false otherwise.
     */
    function hash_equals($known_string, $user_string)
    {
        $result = 0;

        if (!is_string($known_string)) {
            trigger_error("hash_equals(): Expected known_string to be a string", E_USER_WARNING);
            return false;
        }

        if (!is_string($user_string)) {
            trigger_error("hash_equals(): Expected user_string to be a string", E_USER_WARNING);
            return false;
        }

        if (strlen($known_string) != strlen($user_string)) {
            return false;
        }

        for ($i = 0; $i < strlen($known_string); $i++) {
            $result |= (ord($known_string[$i]) ^ ord($user_string[$i]));
        }

        return 0 === $result;
    }
}

In PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.sh, un file test_oauth.phpviene creato nella directory principale di Magento. Ti consigliamo di eliminarlo (o almeno non distribuirlo in produzione) perché potrebbe esporre una traccia di stack di eccezioni completa alla persona che chiama l'URL https: //thedomain.tld/test_oauth.php .

Questo vale per le versioni 1.7 MAGENTO

Se si esegue la versione 1.7.0.2 2 di SUPEE 8788 non funzionerà sulla linea 372 tentando di applicare le modifiche a Curl.php:

patching file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client

Le istruzioni dicono che dovremmo ripristinare SUPEE-1533 e installare SUPEE-3941

PROBLEMA: SUPEE-3941 è disponibile solo per Magento CE 1.8-1.9. Puoi provare ad applicarlo per 1.7 e si applicherà. pensosviluppatori di patch Magento dovrebbe rilasciare una versione 3 di SUPEE-8788 per coloro che eseguono magento sotto 1.8 o creare una patch SUPEE-3941 aggiuntiva progettata per la versione sotto 1.8.

A proposito della versione 1 di SUPEE-8788 non si è verificato l' Curl.phperrore in 1.7.0.2 (l'ho testato su molte installazioni)

Suggerimento: se alla fine si riscontrano errori .swf, assicurarsi di comprimere la patch, caricarla sul server e decomprimerla. L'errore WF sparirà.

AGGIORNARE:

Magento ha detto che sostanzialmente va bene installare la patch SUPEE-3941 su una versione Magento 1.7.0.2 per evitare errori sull'applicazione di SUPEE-8788

Original DashboardController.php (1.7.0.2- Non in cache, fresco da magento)

  if ($params = unserialize(base64_decode(urldecode($gaData)))) {

1533 DashboardController.php con patch contiene la seguente modifica

 if ($newHash == $gaHash) {
            $params = json_decode(base64_decode(urldecode($gaData)), true);
            if ($params) {

La patch 8788 apporta la seguente modifica in DashboardController.php

 if (hash_equals($newHash, $gaHash)) {
            if ($params = unserialize(base64_decode(urldecode($gaData)))) {

Come puoi vedere 8788 ha una modifica modificata rispetto al 1533, NON sono sicuro quale sia l'ideale per modificare il file come suggerisce mpchadwick, sostituendo manualmente la modifica 8788 con 1533 dopo aver installato 8788. In sostanza rimuovendo la modifica 8788.

Eventuali suggerimenti?

Metà tentato di contrassegnare questo post come principalmente basato sull'opinione o senza una risposta chiara;)

Le chiavi del modulo sono state aggiunte a un paio di controller, il numero varia a seconda della versione di Magento.

Se riscontri problemi

• Rimozione di un elemento dalla lista dei desideri
• Eliminazione dell'indirizzo di un cliente dalla vista del negozio
• Aggiornamento di un articolo preventivo nel carrello

Dovrai controllare il tuo .phtmlfile di temi e assicurarti di inserire POSTil parametro chiave del modulo in modo che passi il controllo nelle azioni del controller come:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

     public function updatePostAction()
     {
+        if (!$this->_validateFormKey()) {
+            $this->_redirect('*/*/');
+            return;
+        }
+

Questi problemi hanno fatto scattare molte persone nelle patch precedenti, i temi frontend personalizzati con modelli sovrascritti si perdono facilmente quando si applicano le patch.

Tasti Modulo sono spesso aggiunti al .phtmlmodello contenente il modulo come un extra inputcome

<input name="form_key" type="hidden" value="<?php echo $this->getFormKey() ?>" />

Ho incontrato lo stesso problema in swf in 1.9.2.4.

Fox risolto - Seguire i passaggi seguenti.

Passaggio 1. Scaricare il file SSH della patch di sicurezza 8788 a questo collegamento: - https://magento.com/tech-resources/downloads/magento/

Passaggio 2. Dopo aver scaricato la patch di sicurezza 8788 del file SSH, inserire una cartella e creare il file zip della stessa cartella.

Passaggio 3. Caricare la cartella Zip nella cartella magento principale e decomprimere tramite SSH Putty.

Passaggio 4. Eseguire la patch: - $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

* Nota: il file patch contiene interi file binari in formato testo. Ecco perché quando carichi il file SSH 8788 della patch di sicurezza senza file zip, lo stesso file verrà danneggiato. *

Dopo aver appilato SUPEE-8788 non sono più riuscito a caricare i profili "Importa" utilizzando Unirgy_RapidFlow 2.0.0.18, ottenendo un errore 500 (nulla nei registri Apache o HTTPD).

Sono ancora in fase di debug e lavoro con Unirgy per risolvere, ma sembra che il blocco di uploader stia causando il problema ( Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

La patch ha introdotto diverse modifiche al Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Contentgenitore.

Oltre a uRapidFlow, altri moduli di terze parti che consentono il caricamento di file potrebbero rompersi a causa di SUPEE-8788.

Ho ricevuto il seguente messaggio durante l'esecuzione dello script di patch:

can't find file to patch at input line 4753
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
|index 6d0607e..5757be3 100644
|--- downloader/lib/Mage/HTTP/Client/Curl.php
|+++ downloader/lib/Mage/HTTP/Client/Curl.php

Penso che ciò sia dovuto al fatto che ho rinominato la cartella "downloader", seguendo i consigli di https://www.magereport.com .

Ho rinominato temporaneamente la cartella in "downloader", ho applicato la patch correttamente e poi l'ho rinominata con il suo nome segreto.

Anche la patch su 1.9.0.0 ha esito negativo (probabilmente 1.8.0.0 fino alla 1.9.0.1 interessata) a causa di SUPEE-3941. 3941 patch downloader / lib / Mage / HTTP / Client / Curl.php e ora l'8788 fallisce.

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 378.
1 out of 1 hunk FAILED
checking file js/lib/uploader/flow.min.js

Soluzione alternativa per 1.9.0.1 di seguito. Le modifiche sono troppo approfondite, forse è necessario regolare la patch 8788 stessa.

modifica: modifica la patch, cerca Curl.php e sostituisci

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         }

         $this->curlOption(CURLOPT_URL, $uri);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, FALSE);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');

         // force method to POST if secured
         if ($isAuthorizationRequired) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js 

con

diff --git downloader/lib/Mage/HTTP/Client/Curl.php downloader/lib/Mage/HTTP/Client/Curl.php
index c55f88d..31f9f77 100644
--- downloader/lib/Mage/HTTP/Client/Curl.php
+++ downloader/lib/Mage/HTTP/Client/Curl.php
@@ -378,8 +378,8 @@ implements Mage_HTTP_IClient
         $uriModified = $this->getSecureRequest($uri, $isAuthorizationRequired);
         $this->_ch = curl_init();
         $this->curlOption(CURLOPT_URL, $uriModified);
-        $this->curlOption(CURLOPT_SSL_VERIFYPEER, false);
-        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 2);
+        $this->curlOption(CURLOPT_SSL_VERIFYPEER, true);
+        $this->curlOption(CURLOPT_SSL_VERIFYHOST, 'TLSv1');
         $this->getCurlMethodSettings($method, $params, $isAuthorizationRequired);

         if(count($this->_headers)) {
diff --git js/lib/uploader/flow.min.js js/lib/uploader/flow.min.js

Ecco cosa sto ottenendo

Hunk #1 FAILED at 373.
1 out of 1 hunk FAILED -- saving rejects to file downloader/lib/Mage/HTTP/Client/Curl.php.rej
patching file js/lib/uploader/flow.min.js
patching file js/lib/uploader/fusty-flow-factory.js
patching file js/lib/uploader/fusty-flow.js
patching file js/mage/adminhtml/product.js
patching file js/mage/adminhtml/uploader/instance.js
patching file skin/adminhtml/default/default/boxes.css
patching file skin/adminhtml/default/default/media/flex.swf
patching file skin/adminhtml/default/default/media/uploader.swf
patching file skin/adminhtml/default/default/media/uploaderSingle.swf
patching file skin/adminhtml/default/default/xmlconnect/boxes.css

Sembra che Magento rilascerà la versione aggiornata di SUPEE 8788, per correggere la compatibilità con SUPEE 1533. Non sono sicuro che sia una buona idea applicare le correzioni manualmente in questo momento. Le modifiche manuali possono compromettere i futuri aggiornamenti delle patch. Mi piacerebbe sentire i tuoi pensieri.

È stato confermato dal Magento Community Manager. Dal 13 ottobre alle 15:00 EST .. tutte le patch per le versioni inferiori alla 1.9 vengono eliminate dall'elenco di download https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 Vedi post: https://community.magento.com/t5 / Sicurezza-Patch / SUPEE-8788-E-SUPEE-1533-compatibile-Hunk-error / mp / 50514 / luce / falso # M1805

Stiamo ricevendo segnalazioni dei seguenti nuovi problemi che non vedo in altri post:

• Eccezione nelle nuove versioni in alcuni casi: la chiamata al metodo addCrumbs () (nel caso in cui getStoreConfig (web / default / show_cms_breadcrumbs) non sia definita). Non dovrebbe influire sulla patch, solo la versione 1.9.3 / 1.14.3

'Eccezione' con il messaggio 'Tipo di dati non supportato N' in /lib/Unserialize/Reader/ArrValue.php in 1.9.1.0 e possibilmente versioni precedenti quando viene applicata la patch. risolto nella patch versione 2.

Al momento non esistono soluzioni alternative note per tali problemi. Stiamo lavorando per risolverli in una nuova versione di patch.

Uploader si interrompe quando si carica lo stesso file per campioni e collegamenti contemporaneamente per prodotti scaricabili. Si noti che ciò accade solo se si utilizza lo stesso file in entrambe le aree. (Funzionava correttamente prima della patch.)

Per riprodurre, modificare un prodotto scaricabile e fare clic sulla scheda Informazioni scaricabile :

1. Apri la riga Samples della fisarmonica e cerca un file di esempio.
2. Nella riga Collegamenti della fisarmonica, cercare un collegamento per il download
3. Fai clic su Carica file nella sezione Collegamenti.

L'autore del caricamento carica il file di esempio anziché il file di collegamento scaricabile e il file cercato nella sezione collegamento scaricabile scompare.

Sono stato in grado di riprodurre questo su un'installazione vanilla, patchata 1.7.0.2 CE.

Sì, ho riscontrato altri problemi durante l'accesso, restituirà sempre questo:

Ho scoperto che è perché nella classe Enterprise_Pci_Model_Observer linea 165,

Invece di:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPassword())) {

Questo risolverà:

if (!Mage::helper('core')->getEncryptor()->validateHashByVersion($password, $model->getPasswordHash())) {

Dal momento che non mi piace cambiare core (anche passare a locale), è meglio se Magento risolve questo problema o chiarisca questo. Al momento il mio sta creando nuove estensioni per estenderlo e creare una funzione per getPassword () (dal momento che voglio assicurarmi che tutti gli sviluppatori utilizzino la modalità sviluppatore su).

Modifica del file patch

Se qualcuno deve modificare il file patch, non dovresti farlo in un editor in quanto ciò spezzerà i file binari incapsulati nella patch.

Se hai una riga di comando a portata di mano, ad es. linux / * unix prova a usare l' sedutility per rimuovere linee specifiche.

Puntelli a @fooman per il suggerimento. Guarda la sua idea originale

Esempio sed -ie '101,111d' PATCH_SUPEE-8788_CE_1.7.0.2_v1-2016-10-11-06-36-18.sh

Questo eliminerà inclusivamente le righe da 101 a 111.

Problemi di invio del modulo.

Se vedi il problema sopra menzionato puoi anche:

<?= $this->getBlockHtml('formkey'); ?>

Per ulteriori informazioni, fare riferimento a questo post Che cos'è getBlockHtml ('formkey')?

CE 1.6.2.0 e SUPEE-3941

Per applicare la patch di sicurezza SUPEE-8788 (versione 2), ( http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new ) si consiglia di applicare prima SUPEE-3941 .

Tuttavia, nella pagina di download della patch, non esiste alcuna patch SUPEE-3941 per CE 1.6.2.0. La patch è disponibile solo per CE 1.8 e 1.9.

Come accennato in questa discussione, sembra giusto applicare la patch SUPEE-3941 disponibile (per CE 1.8 e 1.9) su CE 1.7.

È anche possibile applicare SUPEE-3941 (per CE 1.8 e 1.9) su CE 1.6.2.0? Ho provato ad applicarlo su CE 1.6.2.0 e ho ottenuto il seguente errore:

Checking if patch can be applied/reverted successfully...
-e ERROR: Patch can't be applied/reverted successfully.

checking file downloader/Maged/Model/Connect.php
Hunk #1 succeeded at 489 (offset 3 lines).
checking file downloader/lib/Mage/Connect/Backup.php
checking file downloader/lib/Mage/Connect/Command.php
Hunk #1 FAILED at 64.
Hunk #2 succeeded at 205 with fuzz 2 (offset -44 lines).
Hunk #3 succeeded at 382 (offset -53 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Command/Install.php
Hunk #1 FAILED at 90.
Hunk #2 succeeded at 333 with fuzz 1 (offset 17 lines).
Hunk #3 succeeded at 363 (offset 17 lines).
1 out of 3 hunks FAILED
checking file downloader/lib/Mage/Connect/Packager.php
Hunk #4 FAILED at 268.
Hunk #5 FAILED at 290.
Hunk #6 succeeded at 369 with fuzz 2.
Hunk #7 FAILED at 377.
Hunk #9 FAILED at 428.
4 out of 10 hunks FAILED
checking file downloader/lib/Mage/Connect/Rest.php
Hunk #1 succeeded at 71 with fuzz 2 (offset -11 lines).
checking file downloader/lib/Mage/Connect/Singleconfig.php
Hunk #1 succeeded at 100 (offset -36 lines).
checking file downloader/lib/Mage/Connect/Validator.php
Hunk #1 succeeded at 418 (offset -41 lines).
Hunk #2 succeeded at 431 (offset -41 lines).
checking file downloader/lib/Mage/HTTP/Client/Curl.php
checking file downloader/template/settings.phtml

Un po 'tardi, ma abbiamo riscontrato un problema nella patch SUPEE-8788 V2 che si applica almeno ai file patch per Magento 1.7.0.2 e 1.7.0.1. Probabilmente questo vale anche per tutte le versioni precedenti per le quali esiste una versione patch. La versione Magento dalla 1.8 in poi non è interessata in quanto la patch non cambia i modelli per quelli.

In dettaglio

Nella patch manca un formkey per il file app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Senza di essa il login non funziona al checkout on-page (semplicemente non funziona senza errori).

fissare

Un formkey deve essere inserito come nella seguente patch:

diff --git a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
index 9d15a577b..18483a3c5 100644
--- a/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
+++ b/app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml
@@ -71,6 +71,7 @@
         <h3><?php echo $this->__('Login') ?></h3>
         <?php echo $this->getMessagesBlock()->getGroupedHtml() ?>
         <form id="login-form" action="<?php echo $this->getPostAction() ?>" method="post">
+        <?php echo $this->getBlockHtml('formkey'); ?>
         <fieldset>
             <h4><?php echo $this->__('Already registered?') ?></h4>
             <p><?php echo $this->__('Please log in below:') ?></p>

Per il sito con patch 1533 basta sostituire la riga inferiore da PATCH_SUPEE-8788 *****. Sh:

diff --git app/code/core/Mage/Adminhtml/controllers/DashboardController.php app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index 09ffc4c..367bf8e 100644
--- app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,7 +91,7 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
+            if (hash_equals($newHash, $gaHash)) {
                 if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params) 

di:

diff --git a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
index ab2d654..367bf8e 100644
--- a/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
+++ b/app/code/core/Mage/Adminhtml/controllers/DashboardController.php
@@ -91,9 +91,8 @@ class Mage_Adminhtml_DashboardController extends Mage_Adminhtml_Controller_Actio
         $gaHash = $this->getRequest()->getParam('h');
         if ($gaData && $gaHash) {
             $newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
-            if ($newHash == $gaHash) {
-                $params = json_decode(base64_decode(urldecode($gaData)), true);
-                if ($params) {
+            if (hash_equals($newHash, $gaHash)) {
+                if ($params = unserialize(base64_decode(urldecode($gaData)))) {
                     $response = $httpClient->setUri(Mage_Adminhtml_Block_Dashboard_Graph::API_URL)
                             ->setParameterGet($params)
                             ->setConfig(array('timeout' => 5))
diff --git a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
index da1b14a..b6d72c0 100644
--- a/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
+++ b/app/code/core/Mage/Adminhtml/Block/Dashboard/Graph.php
@@ -444,7 +444,7 @@ class Mage_Adminhtml_Block_Dashboard_Graph extends Mage_Adminhtml_Block_Dashboar
             }
             return self::API_URL . '?' . implode('&', $p);
         } else {
-            $gaData = urlencode(base64_encode(json_encode($params)));
+            $gaData = urlencode(base64_encode(serialize($params)));
             $gaHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
             $params = array('ga' => $gaData, 'h' => $gaHash);
             return $this->getUrl('*/*/tunnel', array('_query' => $params));

Fondamentalmente ha appena ripristinato il 1533 e ha lasciato 8788 lungo.

L'acquisizione di Authorize.net viene interrotta dopo l'applicazione della patch. L'autorizzazione funziona correttamente, ma quando si acquisisce il pagamento per fatturare, viene visualizzato "Errore gateway: è richiesto il numero di carta di credito" . Il file di registro dei pagamenti mostra ora il x_typeparametro passa valore auth_capture, ma prima della patch passava prior_auth_captureche funzionava bene. Qualcuno ha riscontrato questo problema?

AGGIORNAMENTO: risolto il problema - Authorize.net non stava acquisendo

Ho patchato una copia di Magento 1.9.2.4 usando SSH con SUPEE-8788 Ho patchato un'altra copia di Magento 1.9.2.4 usando ftp con SUPEE-8788 Ho patchato una copia di Magento 1.9.1.0 usando SSH con SUPEE-8788 usato una nuova copia di magento 1.9.3.1

In tutti questi siti Web Magento con SUPEE-8788 ho riscontrato lo stesso problema (forse un bug della patch)

Utilizzando prodotti scaricabili e andando in Informazioni scaricabili-> Esempi quando provo ad aggiungere una nuova riga (una o più) facendo clic sulla "X" non riesco più a rimuovere la riga

Non sono così esperto in Magento, sto cercando di trovare una soluzione. Se troverò che pubblicherò, se qualcuno di voi ha qualche soluzione, sarà molto molto utile per me

AGGIORNAMENTO : utilizzando Chrome inspector ho visto questo errore:

******* HO TROVATO LA SOLUZIONE *******

Ho trascorso 2 giorni e spero che questo possa aiutare qualcun altro, questo è un bug in SUPEE-8788

Apri samples.phtml all'interno app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable

Trova la funzione

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        element.down('div.flex').remove();
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

e sostituirlo con

remove : function(event){
    var element = $(Event.findElement(event, 'tr'));
    alertAlreadyDisplayed = false;
    if(element){
        element.down('input[type="hidden"].__delete__').value = '1';
        Element.select(element, 'div.flex').each(function(elm){
            elm.remove();
        });
        element.addClassName('no-display');
        element.addClassName('ignore-validate');
        element.hide();
    }
},

Questo risolverà il BUG

Applicato PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-43 sulla copia di prova del sito che esegue 1.9.2.1 e ha interrotto il checkout. Ripristina la patch e il checkout funziona di nuovo normalmente.

Quando si invia l'ordine, si torna al carrello invece che alla verifica. Penso che aspetterò la versione .1 prima di riprovare.

La nuova e-mail nelle prime ore da Magento afferma che produrranno nuove versioni di patch per affrontare i problemi di compatibilità con SUPEE-1533 e SUPEE-3941. Quindi forse tieni i tuoi cavalli per un po '.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3 e SUPEE-8788 Enterprise Edition 1.14.3 e Community Edition 1.9.3 offrono oltre 120 miglioramenti della qualità, oltre al supporto per PHP 5.6. Risolvono inoltre problemi critici di sicurezza, tra cui: ...

... La patch SUPEE-8788 risolve questi problemi di sicurezza nelle precedenti versioni di Magento. Sfortunatamente, abbiamo scoperto che le patch SUPEE-8788 per Community Edition 1.8 e versioni precedenti e Enterprise Edition 1.13 e versioni precedenti hanno esito negativo se un negozio ha precedentemente applicato patch di sicurezza SUPEE-1533 o SUPEE-3941. Stiamo lavorando per correggere questo problema e forniremo nuove patch nei prossimi 1-3 giorni. Fino ad allora, stiamo rimuovendo queste versioni della patch SUPEE-8788 dalla distribuzione ...

Tuttavia, sono preoccupato per il fatto che le mie versioni Magento attive rientrino tra la CE 1.9.3 che dicono funzionino e le nuove versioni in arrivo per V1.8 e precedenti. Li ho contattati, quindi aspetterò e vedrò cosa dicono.

Non sono un grande fan del patching. Personalmente rimuovo tutti i file di Magento dalle loro directory, quindi carico la nuova versione (usando uno script di shell). Tutti i file installati negli anni come moduli o temi sono ancora lì. Per il database faccio un confronto tra le nuove versioni installate. Un modo è la creazione o la rimozione di colonne / tabelle nel database, l'altro modo è di reinstallare Magento semplicemente cambiando il nome del file /app/etc/local.xml. Preferisco il primo.

Se non si modifica la struttura del database alla versione 1.9.3.0, si otterranno alcuni errori o non è possibile caricare l'area di amministrazione. Se qualcuno è interessato ad alcuni confronti per directory e database Magento tra Magento CE 1.9.2.4 e 1.9.3.0 basta scaricare il file da qui:

Confronto Magento: versioni 1.9.2.4 - 1.9.3.0

Ci sono due file HTML con risultati visivi molto belli.

Oggi ho aggiornato 4 negozi usando il mio metodo invece di patch. Tutti sono in esecuzione senza problemi.

Non avendo fortuna sulla maggior parte delle installazioni di Magento CE (6 in totale). Diverse versioni: 1.9.1, 1.9.0.1, 1.8.1.

Ho scaricato la patch 8788 corrispondente corretta. Mi sono assicurato di ripristinare il 1533 quando applicabile.

Ottengo i seguenti risultati chiave che sono discutibili:

Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

...

checking file downloader/lib/Mage/HTTP/Client/Curl.php
Hunk #1 FAILED at 372.

... il controllo del file app / code / core / Mage / Adminhtml / controller / IndexController.php Hunk # 1 è riuscito a 373 (offset -19 righe). ...

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.ph

Come sopra per: lib / Unserialize / Reader / Arr.php lib / Unserialize / Reader / ArrValue.php E dice che questi hunk sono stati ignorati.

nota: non c'è nulla nella mia directory Unserialized / Reader. Completamente vuoto. nota: Curl.php è nella directory downloader. Non rinominato. Termina, ma non vedo i file SWF rimossi. Non vedo la patch applicata nell'elenco di application.patches.list

Non ha senso.

Oggi ho patchato circa 10 siti Web e ogni sito in cui la patch SUPEE-8788 ha fallito presentava il SUPEE-6788 MISSING .

Ciò ha comportato (esempio) il seguente errore:

can't find file to patch at input line 5810
|diff --git lib/Unserialize/Parser.php lib/Unserialize/Parser.php
|index 423902a..2c01684 100644
|--- lib/Unserialize/Parser.php
|+++ lib/Unserialize/Parser.php

Dopo aver installato SUPEE-6788, SUPEE-8788 è stato corretto correttamente.

Se stai ricevendo l' Hunk #1 failederrore xxx, questo è quello che ho fatto

Ho capito Hunk #1 failed at 373. Errore !! dopo la linea

controllo del downloader di file / lib / Mage / HTTP / Client / Curl.php

Quindi ho controllato il Curl.phpfile e ho scoperto che avevo modificato il file prima (commentato una riga). Ho ripristinato il file originale ed eseguito nuovamente la patch. Quindi la patch ha avuto successo. ;).

Quindi ho controllato:

/app/etc/applied.patches.list e tutto sembra a posto