Patch di sicurezza SUPEE-9767 - Possibili problemi?


108

Una nuova patch di sicurezza è disponibile per Magento 1, risolvendo 16 problemi APPSEC: https://magento.com/security/patches/supee-9767

Sette delle vulnerabilità hanno un punteggio di 8.0 o superiore per CVSSv3 Severity e vengono sfruttate in natura, quindi questa è una patch critica. I siti possono applicare SUPEE-9767 o aggiornare alla nuova versione CE 1.9.3.3 / EE 1.14.3.3.

Quali sono i problemi comuni o le insidie ​​a cui prestare attenzione quando si applica SUPEE-9767?


AGGIORNAMENTO 2017-07-12:

Magento ha rilasciato SUPEE-9767 V2 e CE 1.9.3.4 per risolvere molti dei problemi della patch iniziale. Se hai applicato V1, dovresti ripristinare e quindi applicare V2. Se non hai ancora patchato, applica solo V2 e la maggior parte dei problemi sollevati qui non saranno rilevanti.


"Sette delle vulnerabilità hanno un punteggio di 8.0 o superiore per CVSSv3 Severity e vengono sfruttate in natura, quindi questa è una patch critica." Volevo solo controllare, l '"attaccante" ha bisogno di entrare in admin per fare uno di questi exploit?
PaddyD

3
sì, devi avere l'accesso come amministratore per sfruttare ...
MagenX

La patch non sembra fermare l'endpoint comune della forza bruta (ovvero / rss / order / new) quale sembra essere il modo più comune con cui i botters stanno tentando di accedere alle aree di amministrazione?
Ricky Odin Matthews,

1
Lo uso per RSS @RickyOdinMatthews in .htaccess RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC]
Richard Feraro il

@RichardFeraro Uso nginx, ma utilizzo già una soluzione simile. Ho notato che i robot in genere cercano e forza bruta questi endpoint però.
Ricky Odin Matthews,

Risposte:


107

Ecco la mia panoramica della patch dopo averla scavata

TIME SAVER : Experius fornisce un supporto per le patch che ti aiuta a trovare i file in temi personalizzati, moduli personalizzati o sovrascritture locali che potrebbero anche dover essere patchati manualmente , puoi trovarli qui: https://github.com/experius/Magento- 1-Experius-Patch-Helper # magento

Chiavi del modulo di pagamento

Come detto nell'altro post, questa patch aggiunge le chiavi del modulo ai seguenti moduli:

Modulo carrello di spedizione:

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

Modulo di pagamento per fatturazione multishipping:

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

Modulo di spedizione per spedizioni multiple:

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

Modulo per il checkout di indirizzi multishipping:

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

Modulo di pagamento per la fatturazione:

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

Modulo di verifica della spedizione:

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

Modulo di pagamento:

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

Modulo di verifica del metodo di spedizione:

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

Modulo di pagamento per fatturazione persistente:

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

Inoltre, i seguenti file JS sono stati aggiornati per essere compatibili con tale modifica:

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

Cosa fare:

Se lo stai utilizzando con versioni personalizzate di tali modelli, dovrai aggiornarli aggiungendo il seguente codice:

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

Se stai utilizzando un modulo di pagamento di terze parti, dovrai metterti in contatto con loro in modo che possano fornire una versione aggiornata del loro modulo.

Inoltre, se disponi di versioni personalizzate dei file JS precedentemente elencati, dovrai aggiornarli.

SALVA IL TUO TEMPO :

Fabian Schmengler ha scritto una bella sceneggiatura per aggiornare tutte quelle cose per te, puoi trovarla qui:

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

NOTA IMPORTANTE : la convalida del formkey di checkout può essere modificata nel backend tramite un nuovo campo di configurazione in Sistema> Configurazione> Ammin.> Sicurezza> Abilita convalida chiave modulo al momento del pagamento . QUESTO NON È ABILITATO DA DEFAULT, quindi dovrai abilitarlo per beneficiare di questa funzione di sicurezza !!! Nota che riceverai un avviso nel backend se non è abilitato.

Richiamata caricamento immagine

Il controller della galleria di immagini è stato aggiornato per aggiungere un callback di convalida.

Cosa fare

Se stai utilizzando un modulo personalizzato che esegue il caricamento delle immagini con un codice simile al seguente:

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

Consiglio vivamente di aggiornare quel codice aggiungendo il seguente pezzo:

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

link simbolici

Questa patch rimuove il campo di configurazione del sistema che consente di consentire collegamenti simbolici al modello nel back-end. In passato si trovava in Sistema> Configurazione> Sviluppatore> Modello> Consenti collegamenti simbolici . Ora l'intera sezione del modello è sparita.

Inoltre, quel campo è ora disabilitato per impostazione predefinita tramite il app/etc/config.xml

La cosa divertente qui è che riceverai un avviso nel backend se hai quel campo di configurazione abilitato prima della patch ma non sarai in grado di disabilitarlo poiché il campo non c'è più.

L'unico modo per farlo è eseguendo la seguente query SQL

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

Una precisazione

Innanzitutto ti consiglio vivamente di controllare quei due post che ti aiuteranno a capire lo scopo di quella modifica di Symlink:

Questa modifica riguarda davvero la chiamata di contenuti caricabili (come le immagini) tramite le direttive del modello.

Il problema relativo ai collegamenti simbolici è sfruttabile solo con l'accesso dell'amministratore e Magento ha aggiunto anche un po 'più di protezione ai caricamenti di immagini.

Si noti che sono alcune protezioni contro il modo noto di sfruttarlo oltre all'impostazione stessa.

Cosa fare : se come me, stai usando modman o compositore con collegamenti simbolici modello, dovrai affrontare alcuni problemi. Sto ancora cercando di scoprire qual è la cosa migliore da fare qui oltre a gestire le query SQL.

Post principale su questo problema: SUPEE-9767, modman e symlink

Elenco di possibili problemi

V2 è stato rilasciato da quel post originale. Non dimenticare di aggiornare

bugs

La parola "confermato" viene utilizzata per i bug confermati. Se non è presente, significa che potrebbe essere un bug ma non è stato ancora confermato.

Hunk Problemi non riusciti

Nota che tutti questi problemi potrebbero essere semplicemente dovuti alla modifica del file originale, per verificare che non sia così:

  • Eseguire il backup del file in cui viene visualizzato l'errore Hunk Failed
  • Scarica il file originale dalla tua versione di Magento
  • Confronta entrambi i file

Se i file sono diversi, dovrai applicare la patch con il file originale, quindi riapplicare le modifiche personalizzate in modo pulito come:

  • modello personalizzato in una cartella di temi personalizzati
  • local.xml
  • app / codice / file locale

Se i file non sono diversi, si tratta di un problema di autorizzazione o di un "bug" nella patch.


1
@Icon no. Per ricontrollare, usa lo strumento a cui ho fatto riferimento nella parte superiore della mia risposta
Raffaello al Pianismo digitale,

1
solo per aggiungere all'elenco di "altri problemi": sembra che magento.stackexchange.com/questions/167616/… non sia stato corretto anche nell'ultima versione
Anton Boritskiy,

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

1
Un'altra aggiunta all'elenco: la patch interrompe il multishipping per il tema predefinito magento.stackexchange.com/questions/177681/…
Aad Mathijssen,

1
'Filigrana diventa sfondo nero quando trasparente' - può confermare che questo è corretto. Questo succede quando carichi un png trasparente in cms
pixiemedia,

42

Problema 1: form_key non valido alla pagina di pagamento

Magento aggiunge form_keynella maggior parte dei moduli.

se lo hai using default onepage and using custom theme, inizierai a ricevere ** form_keyproblema alla cassa ogni passaggio **;

dovresti aggiungere la chiave del modulo in <?php echo $this->getBlockHtml('formkey') ?>

per formare ogni file di passaggio del checkout se i file sottostanti escono,

  • 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

se i file modello vengono richiamati dal tema di base , non crea problemi. Perché la patch aggiornerà automaticamente quei file.

Nota anche: <?php echo $this->getBlockHtml('formkey') ?>dovrebbe essere sempre all'interno del tag del modulo

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

** Se si utilizza il checkout multi-spedizione Magento, è necessario farlo all'indirizzo

sotto i file:

Problema2: emissione form_key al modulo di stima della spedizione nella pagina del carrello:

Aggiungi form_key al modulo di spedizione preventivi alla pagina del carrello

Quindi deve aggiungere la chiave del modulo <?php echo $this->getBlockHtml('formkey') ?>

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

Problema3: errore opcheckout.js di checkout di Magento onepage

Se si utilizza il checkout predefinito sulla pagina e opcheckout.js si dovrebbe verificare

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {è disponibile su opcheckout.js

In caso contrario, sostituire

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

con

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

In caso di issue1, issue2, issue3, Issue può essere risolto facilmente utilizzando lo script di @FabianSchmengler add-checkout-form-key.sh . Risolverà il problema sui file dei temi ricettivi

Problema 4: chiave del modulo non valida dopo il login del cliente quando riscrive Mage_Customer_Model_Session

Se la Mage_Customer_Model_Sessionclasse riscrive o ha chiamato da

app/code/local/Mage/Customer/Model/Session.phpquindi potresti ricevere un problema form_key quando impostiamo un cliente per la sessione utilizzando setCustomerAsLoggedIn()/ o dopo un cliente impostato nella sessione.

In questo caso, devi essere aggiunto

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

at setCustomerAsLoggedIn () prima della chiamata di

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

Problema5: problema Form_key dopo il logout

Dopo aver disconnesso il cliente dalla sessione , è possibile che si avvii il problema della sessione se la Mage_Customer_Model_Sessionclasse riscrive o se ha chiamato da

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

In quelle stesse necessità per questo caso:

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

Raccomandazione:

Consiglio1: risolto il problema di supee-9767 , è possibile utilizzare la patch https://github.com/experius/Magento-1-Experius-Patch-Helper

Questa è una soluzione migliore per ora.

Si noti , prima di farlo, si consiglia vivamente di eseguire il backup di file e database o backup completo del sistema.


Raccomandazione2: utilizzare la funzione patch sul ONESTEP CHECKOUT

Sappiamo che la patch supee-9767 è stata rilasciata per motivi di sicurezza, se si utilizza ONESTEP CHECKOUT, è necessario aggiungere la convalida form_key all'operazione SAVE del controller di checkout onestep .

Supponiamo che per salvare i dettagli del metodo di spedizione, il tuo checkout onestep abbia usato saveShippingmethod () Quindi su questo dovresti aggiungere

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

Inoltre, è necessario aggiungere la chiave del modulo <?php echo $this->getBlockHtml('formkey') ?> nella sezione relativa alla verifica dei file phtml

Alcuni link correlati

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


1
One-liner piacevole e veloce per trovare i file del modello personalizzato per la chiave del modulo in checkout; trova app / design / frontend | grep -E "checkout / onepage / (fatturazione | pagamento | spedizione | shipping_method) .phtml" | grep -v "base / default" | grep -v "rwd / default"
Peter Jaap Blaakmeer,

6
o aggiornali immediatamente con uno leggermente più lungo: gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b
Fabian Schmengler,

questa è la magia di @FabianSchmengler !!! :)
Amit Bera

@FabianSchmengler fantastico, ha funzionato!
Peter Jaap Blaakmeer,

1
@AmitBera FYI: alcuni plugin di checkout utilizzano AJAX per inviare fatturazione / spedizione / ecc. Ho dovuto solo rattopparne uno. Un modo semplice per farlo è mettere <script> var formKey = "<? Php echo Mage :: getSingleton ('core / session') -> getFormKey ();?>"; </script> in testa al tema. Quindi è possibile aggiungere form_key: formKey come parametro all'invio AJAX. Ovviamente prova i moduli dopo per confermare l'invio del nuovo parametro e modifica il controller per gestirlo come indicato nel tuo post.
Kalvin Klien,

26

Basato sul mio primo passaggio alla revisione del file patch ...

  • È admin/security/validate_formkey_checkoutstata aggiunta una nuova impostazione . Quando attivato, i moduli di verifica vengono controllati per la presenza di una chiave del modulo. Se i file modello sono sovrascritti nel tema, dovranno essere aggiornati lì. Questa impostazione sembra essere disattivata per impostazione predefinita
  • I collegamenti simbolici sembrano non essere consentiti per impostazione predefinita (in app/etc/config.xml). Inoltre, la possibilità di consentirli sembra essere stata rimossa dalla configurazione dell'amministratore. Tuttavia, se il tuo sito in precedenza aveva esplicitamente abilitato i collegamenti simbolici, l'impostazione sarebbe stata salvata nel database, ignorando questa modifica.
  • È necessario cancellare sia la cache che l'intera cache della pagina quando si applica questa patch. Le eccezioni di progettazione vengono salvate in un formato incompatibile con la decodifica. Vedrai un errore come questo "Decodifica non riuscita: errore di sintassi" se non svuoti la cache della pagina.

1
Potresti anche entrare con un editor esadecimale e aggiungerlo tu stesso al database, ma potrebbe essere un po 'troppo per la maggior parte delle persone
cat

1
Se alcuni di voi utilizzano CDN, come cloudflare, assicurarsi di eliminare la cache. Ho provato ad andare alla cassa con la CDN attiva e non sarebbe andata oltre la pagina dei Pagamenti. Nel momento in cui ho eliminato la cache e abilitato la modalità di sviluppo, è andato tutto bene.
Icona

14

Sotto il base/defaultfile interessato da questa patch, se questi file erano nel tuo tema, ti preghiamo di apportare le modifiche di conseguenza

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 tutti i phtmlfile sopra riportati viene aggiunta la riga chiave del modulo, quindi si prega di aggiungere questa riga nel rispettivo file phtml.

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

Per quanto sopra, @fabian ha creato uno script che aggiungerà la chiave del modulo anche nel file del tema

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

dopo aver applicato la patch di sicurezza se si ottiene un errore per la chiave del modulo, è possibile applicare questa patch, poiché l'applicazione di questo processo di patch è uguale alla patch di sicurezza

  sh filename.sh

e una base/defaultmodifica nel Jsfile

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

quindi se questo jsfile si sta caricando dal tuo tema, fai quanto segue

rimuovere la linea di soffiaggio

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

e aggiungi sotto la riga anziché sopra

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

MODIFICARE

E se stai usando un'estensione di checkout che sovrascrive i file seguenti, aggiungi la riga chiave del modulo nel file phtml dell'estensione di checkout.

EDIT2 - Problemi

1) Errore in saveBillingAction () o acquisizione della chiave del modulo null o Problema della chiave del modulo: Patch 9767 che ottiene la chiave del modulo non valida

2) Hunk # 1 FAILED at 225. 1 hunk su 1 FAILED - salvataggio degli scarti nel file app / design / frontend / enterprise / default / template / persistente / checkout / onepage / billing.phtml: SUPEE-9767 - Hunk # 1 GUASTO a 225. 1 pezzo su 1 pezzo FAILED

3) salvataggio degli scarti nel file app / code / core / Enterprise / PageCache / Model / Observer.php.rej: ERRORE SUPEE-9767: la patch non può essere applicata / ripristinata correttamente

4) SUPEE-9767, modman e symlink: SUPEE-9767, modman e symlink

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

6) 1 pezzo su 1 FAILED - salvataggio degli scarti nel file app / codice / core / Mage / Sales / Model / Quote / Item.php: Magento 1.9.2.2 SUPEE-9767 Patch ERROR

7) errore di verifica onestep (anche in questo caso si tratta del problema relativo alla chiave del modulo): SUPEE-9767 Magento CE 1.9.3.3 Checkout Onestep non funzionante con convalida chiave modulo al checkout abilitato

8) problema di registrazione del cliente di checkout in un'unica fase: SUPEE-9767 Patch / CE 1.9.3.3 - Pagamento di una pagina - Problema di registrazione del cliente

9) app / code / core / Mage / Core / Model / File / Validator / Image.php: Magento SUPEE 9697 1.9.2.2 fallisce in Image.php


1
La versione 2 della patch dovrebbe essere presto disponibile. I bug dovrebbero essere corretti.
Icona

1
@icon aspettando la v2
Murtuza Zabuawala il

9

Si noti che i collegamenti simbolici sono sempre stati disabilitati per impostazione predefinita sulle nuove installazioni di Magento admin SÌ / NO valori di configurazione predefiniti su "NO". L'aggiornamento ora disabilita esplicitamente i collegamenti simbolici in config.xml e come ulteriore precauzione rimuove anche la sezione del modello da admin-> developer che conteneva l'opzione di configurazione.

Ciò non influirà sulle impostazioni correnti del collegamento simbolico, se i collegamenti simbolici attivati ​​manualmente prima della 1.9.3.2 rimarranno abilitati, sebbene non sia più possibile visualizzare l'impostazione in admin.

Gli utenti che utilizzano modman per gestire i moduli Magento 1.x devono assicurarsi di non disabilitare i collegamenti simbolici poiché ciò disattiverà i moduli modman.

Gli amministratori responsabili possono abilitare nuovamente la sezione admin del link simbolico cercando le modifiche alla sezione template in app / code / core / Mage / Core / etc / system.xml e aggiungendo la sezione a system.xml intorno alla riga 600. Oppure i link simbolici doppio controllo sono ancora abilitati con

n98-magerun.phar config: dump | collegamento simbolico grep

Ecco il file diff per magento1933 e magento1932 per aiutare a identificare le modifiche nel tema predefinito che possono influire sui temi personalizzati / estesi.

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


Perché hanno rimosso l'opzione Symlink ?, esiste ora un exploit aperto al pubblico (al di fuori dell'utente amministratore) o è solo un rischio se si trova in un ambiente condiviso?
PaddyD,

questa discussione sembra rispondere alla mia domanda: magento.stackexchange.com/questions/176952/…
PaddyD

I collegamenti simbolici sono disabilitati per un motivo. Suggerisco di copiare invece di symlink: magento.stackexchange.com/a/177149/54863
Barryvdh

9

Problema: l'uso di php7 a volte genera il seguente errore:

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}

È abbastanza sicuro che la versione di Zend debba farci qualcosa. Una soluzione rapida è questa ma non è certo corretta:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 sostituiscilo con:

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

-> e app / code / core / Enterprise / PageCache / Model / Observer.php: 177 con:

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

Naturalmente crea un addon per riscriverlo. Ma sono sicuro che c'è qualcosa di meglio da fare qui.

AGGIORNAMENTO (soluzione migliore)

-> Vai a: lib / Zend / Json.php e dopo la riga 76 aggiungi questo:

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

Crea l'estensione per sovrascriverla e non modificare il file principale.


La cache è stata completamente cancellata. Questo non è lo stesso problema.
folektoras133,

2
Abbiamo riscontrato lo stesso problema: il ripristino di app / code / core / Enterprise / PageCache / Model / Observer.php ha rimosso il problema, ma ovviamente non è la soluzione corretta, solo la prevenzione a:5:{i:0;s:29:"Decoding failed: Syntax error";i:1;s:1376:"#0 app/code/core/Enterprise/PageCache/Model/Observer.php(177): Zend_Json::decode('a:0:{}')
Judder

9

Problema: il codice dinamico o CSS disabilita l'elemento di input chiave del modulo al momento del pagamento

Un problema che ho riscontrato è dove il codice dinamico (paypal plus) nel processo di checkout di una pagina sovrascrive l' elemento fieldset nel metodo di pagamento in un passaggio form html - eliminando o disabilitando (con css) l'elemento nascosto form_key.

La correzione è garantire che l' elemento formkey non sia disabilitato da alcun codice dinamico o CSS. Anche spostare il codice formkey all'esterno dell'elemento fieldset può essere d'aiuto

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

Puoi facilmente confermare se il form_key viene rilevato e inviato al controller di una pagina ispezionando le richieste di rete ajax nel tuo browser mentre passi i metodi di checkout, ogni metodo dovrebbe includere la chiave del modulo nei dati del modulo ajax, se il modulo La chiave non è presente ma il codice sorgente di Magento è stato corretto per verificare che il codice esterno influisca sull'elemento chiave del modulo, vale a dire css o modifiche dinamiche sul lato client.

inserisci qui la descrizione dell'immagine


2
Questa soluzione non sembra funzionare per me con EE. Ho scoperto che anche il file app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml doveva essere aggiornato: le righe 35-38 devono essere aggiornate per includere || elements[i].name == 'form_key'insieme agli altri selettori per mantenere disabilitato il campo modulo form_key.
Greg Nickoloff,

Grazie g-man1066! Quello era esattamente il problema che stavo avendo.
Grafikchaos,


8

PROBLEMA: la registrazione del cliente non riesce quando si utilizza il checkout in 5 passaggi Magento generico.

Questo problema viene presentato solo quando ABILITIAMO l'autenticazione con chiave. Versione utilizzata: 1.7.0.2, ma sembra che qualcuno abbia pubblicato lo stesso problema anche nella versione 1.9.3. SUPEE-9767 Patch / CE 1.9.3.3 - Pagamento in una pagina - Problema di registrazione del cliente

Quando vai alla cassa, ci vengono presentate 2 opzioni: VERIFICA COME OSPITE O REGISTRATI Dopo aver fatto clic su "Registrati" e compilando il modulo insieme alla password, procedi attraverso tutti i passaggi e completa l'ordine. L'ordine viene effettuato, MA il cliente non viene mai registrato in magento. Sembra che l'ordine sia stato effettuato dall'ospite.

Quando sono tornato e disabilitato l' autenticazione con chiave del modulo, e ho provato a effettuare l'ordine durante la registrazione come cliente, è stato effettuato senza problemi e il cliente è stato registrato nel back-end.


1
Ecco un post più dettagliato su questo problema magento.stackexchange.com/questions/177035/…
Raphael at Digital Pianism

8

AGGIORNAMENTO 13/07/2017 [IL PROBLEMA È RISOLTO]

Il team di Magento ha rilasciato SUPEE-9767 V2 in questa versione della patch il problema con gif e png trasparenti è stato risolto.

È necessario ripristinare tutte le modifiche al file discusso in questo thread. Quindi ripristina la patch V1 applicata e infine applica la nuova versione V2.


PRE - SUPEE-9767 V2

Si prega di non usare il codice discusso qui sotto invece applicare V2 della patch, il problema discusso qui sotto è già risolto in questa versione

Se qualcuno ha problemi con i PNG trasparenti che quando vengono caricati dal pannello di amministrazione lo sfondo diventa nero. (Sui prodotti) è in relazione al callback di Image Upload introdotto in:

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

Al momento non sono sicuro di cosa stia causando esattamente questo comportamento, ma sto cercando di capirlo, posso confermare che quando il callback viene rimosso lo strano comportamento scompare.

inserisci qui la descrizione dell'immagine

AGGIORNARE

Ok, ho trovato la funzione che è anche aggiornata da SUPEE-9767 questo sta effettivamente rompendo la trasparenza nei png è una copia dell'immagine originale creata senza trasparenza.

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

AGGIORNARE

Ecco la versione aggiornata della funzione per preservare la trasparenza del png

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

queste due righe devono essere aggiunte alla patch. Aggiorna la funzione 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.'));
}

AGGIORNAMENTO 23/06/17

Questa versione aggiornata della funzione corregge il PNG e la trasparenza GIF.

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

1
Ciò ha risolto il mio problema in un'installazione di Magento 1.7. Grazie!
Tjitse,

Nessun problema Tjitse prende nota di questa modifica nel caso in cui il team di Magento non risolva la patch che dovrà essere ripristinata quando si esegue la patch successiva. Ho inviato il problema alla community su bugcrowd.com spero che introdurranno presto la correzione della patch.
Daniel Yovchev,

questo lo risolve per i png, ma non per i file gif trasparenti. i file gif richiedono una gestione leggermente diversa usando imagecolortransparent
alternano il

Grazie per averlo segnalato alternate vedi la funzione aggiornata che corregge anche la trasparenza gif.
Daniel Yovchev,

7

Problema: consenti la notifica del collegamento simbolico non mostrata agli amministratori

La notifica del collegamento simbolico non verrà visualizzata nell'area di notifica dell'amministratore in quanto non è inclusa in <block type="core/text_list" name="notifications" as="notifications">

La patch per CE e EE di seguito:

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

Il problema è </block>alla fine di checkout_formkey(che è auto-terminante) e quindi chiude il genitore notifications. Ciò causa il notification_symlinknon essere incluso nel core/text_liste non essere reso.


Questo non è davvero un problema, la notifica è stata rimossa perché i collegamenti simbolici sono stati esplicitamente disabilitati e la sezione di configurazione del collegamento simbolico è stata rimossa. Non è possibile modificare manualmente il valore del collegamento simbolico in admin nella v1933, quindi mostrare una notifica di amministratore è piuttosto inutile. Il problema riguarderà le nuove installazioni del 1933 in cui gli utenti che richiedono collegamenti simbolici, ad esempio per modman, non possono più abilitarlo manualmente. Si potrebbe dedurre che Magento non si aspetti nuove installazioni 1.x ...
paj

Non sono d'accordo, questa patch non disabilita esplicitamente la configurazione se è già impostata - la disabilita solo se non è già impostata. Pertanto, se un'istanza ha dev / template / allow_symlink impostato su yes nel DB / local.xml prima di questa patch e applicano la patch, DOVREBBE ricevere l'avviso che i link simbolici sono consentiti in quanto potenzialmente vulnerabili.
mwylde,

Vedo il tuo punto e tu hai ragione. Ma per un utente normale cosa farebbe allora - è impossibile disabilitarlo manualmente dall'amministratore poiché l'opzione di configurazione è stata rimossa. È un po 'una situazione di cattura 22 ...
paj

7

Piccolo consiglio per #patchday; dopo aver copiato 1.9.3.3 sulla tua installazione, esegui git diff -w --stat | grep -v " 2 +" | grep -v " 0"per vedere rapidamente maggiori cambiamenti nei file.


7

Problema: modello di spedizione EE non patchato

Ho patchato un'installazione EE 1.13.1.0 e il modello di spedizione aziendale ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) non ha aggiunto il formkey, ma i modelli di fatturazione e pagamento sì.

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


Avevo anche bisogno (per EE 1.14.2) di aggiungere il form_key a /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtml,.../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml
Greg Nickoloff il

4

Si è verificato un problema con le versioni EE di Magento che sono patchate con SUPEE-9767 (quindi non con aggiornamenti a 1.14.3.3). La chiave del modulo in quella pagina verrà memorizzata nella cache. Quindi quando svuoto la cache e poi vado a una pagina del prodotto e mi assicuro che la pagina sia completamente memorizzata nella cache (aggiorna un paio di volte), dovrei essere in grado di aggiungere quel prodotto al mio carrello.

Ora, quando apro un altro browser (o modalità di navigazione in incognito), apro la stessa pagina e provo ad aggiungere nuovamente il prodotto al carrello. Il prodotto non verrà aggiunto al carrello, a causa della chiave del modulo. Ora, quando si scarica nuovamente la cache, il prodotto può essere aggiunto nuovamente al carrello.

Grazie a Jasper Zeinstra


3

Per gli sviluppatori che utilizzano Magento Composer Intaller, è possibile modificare la strategia di distribuzione in Copia anziché in Symlink. Puoi anche configurare per aggiungere i file del modulo al tuo .gitignore, in modo che il tuo repository rimanga pulito.

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


Abbiamo scoperto che con la copia "magento-force": true,diventa importante
Jeroen il


2

Problema: la patch funzionava su Magento vaniglia 1.7.0.0 [modificato]

Durante il test del nostro script di patch abbiamo scoperto un problema nella patch per Magento 1.7.0.0. Non so se qualcuno lo utilizza ancora, ma comunque è un problema in SUPEE-9767. Abbiamo usato un'installazione vanilla e abbiamo installato prima tutte le patch precedenti.

File di patch utilizzato: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh Il file di patch non funziona per Magento 1.7.0.1 e 1.7.0.2

Riepilogo dei problemi:

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

Per la cronaca, questo sulla 1.7.0.0 abbiamo provato la patch su:

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

4
Se manca quel file, molto probabilmente non è stata applicata la patch di sicurezza SUPEE-7405.
Ryan Hoerr,

@RyanHoerr hai ragione, SUPEE-7405 è stato ignorato perché il file ufficiale PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.shnon funziona per 1.7.0.0. Ho creato una versione fissa del file. Se qualcuno ne ha bisogno, mandami un messaggio.
Jeroen Vermeulen - MageHost,

2

Ho dovuto ripristinare questa patch a causa di un comportamento strano. Per qualsiasi motivo, alcuni utenti non sono stati in grado di aggiungere determinati articoli al carrello.

Suppongo che abbia qualcosa a che fare con le vecchie citazioni che si scontrano con l'attuale quotazione per quel cliente. Ho verificato questo problema accedendo come utente per assicurarmi che non fosse solo un 1D10T.

È stato un problema da quando ho preso quella vita di patch venerdì scorso. Stiamo usando 1.14.2.4 . Siamo pesantemente modificati, quindi potrebbe funzionare bene per altri utenti. Solo un avvertimento!


Questo è corretto, la patch interrompe l'azione Aggiungi al carrello per la versione EE di Magento. Fondamentalmente, il problema si verifica a causa del modulo PageCache con una versione della logica di generazione form_key, mentre la sessione ha la sua. Quando FPC ha la versione cache della pagina richiesta, ma deve rigenerare la minicart, viene avviata la sessione che rigenera form_key nello stesso momento in cui viene chiamato il salvataggio FPC che genera il proprio form_key. A quel punto il valore della sessione di form_key differisce da quello memorizzato nel cookie del cliente (utilizzato nel processore FPC), quindi ottieni una chiave non valida su aggiungi al controller del carrello.
Stjepan,

Sto riscontrando anche questo problema. Ti farò sapere se trovo una soluzione.
cmtickle

Ho risolto questo problema, spiegazione qui: magento.stackexchange.com/questions/177942/…
cmtickle

Qualcuno sa se questo è stato risolto in SUPEE-9767 v2?
Discepolo di Uno

2

Problema: ciclo di reindirizzamento infinito su 1.6.0.0

Soluzione rapida

Trova le righe sottostanti all'interno della funzione protetta metodo _checkBaseUrl ($ request) nel file 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
 ) {  

Cambia queste righe in

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

Successivamente, salva il file (esegui il commit nel tuo REPO), svuota la cache (rimuovi tutto nella cartella var / cache) e ricarica la parte anteriore del negozio. Dovresti trovare il sito caricato senza più 302 problemi di reindirizzamento dopo aver applicato la patch SUPEE 9767.

Causa ultima

La differenza nel valore SCHEMA tra la richiesta effettiva e l'URI dopo il reindirizzamento. Ad esempio: la richiesta effettiva restituisce lo schema HTTP ma lo schema nell'URI può essere HTTPS.

Possibili ragioni sottostanti

  1. Molto probabilmente potresti avere una regola di reindirizzamento nel file .htaccess per reindirizzare tutte le richieste http su https. L'utente richiede http://tuodominio.com e potresti aver modificato lo schema e reindirizzato a https: // tuodominio invece di http://tuodominio.com che aveva effettivamente richiesto.

  2. Entrambi gli URL di base sicuri e non sicuri iniziano con https


2

Il BUG CONFERMATO "La registrazione del cliente fallisce alla cassa" si è verificato un po 'diverso dalla mia parte.

Se il cliente sceglie di registrarsi al checkout, la sua password non viene memorizzata correttamente. Il cliente viene creato correttamente solo se la password non è memorizzata. L'ho rilevato dal fatto che la password non è stata mostrata nell'e-mail di benvenuto. Le persone non possono accedere anche per questo.

Bugfix collegato in SUPEE-9767 Patch / CE 1.9.3.3 - Verifica di una pagina - Il problema di registrazione del cliente ha fatto il lavoro anche per me.


2

Qualcuno può dirmi che cosa f ... è questo s ... per supee-9767?

inserisci qui la descrizione dell'immagine


1
La versione jQuery 1.10.2 è considerata vulnerabile e contrassegnata da alcuni scanner PCI. La versione 1.12 non lo è.
Ryan Hoerr,

@Detzler StackExchange non è un forum. Se vuoi fare una domanda, devi pubblicarne una, non una risposta a una domanda.
toon81,

1
Ryan Hoerr ha chiesto informazioni su eventuali problemi causati dalla patch. Quindi gli ho detto un possibile cambiamento di rottura come vedi nello screenshot. Non riesco a spiegare il motivo di questo cambiamento. Quindi ho chiesto sotto. Quindi qual è il tuo problema?
Detzler,

2

La patch non funziona nemmeno per un Magento vaniglia 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

anche dopo aver applicato manualmente le patch più vecchie.

$ 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

La soluzione / problema che ho riscontrato è che alcune delle modifiche nella patch per 1.7.0.2 riguardano file che non esistevano prima della 1.9.2.3. Quindi ho copiato i seguenti file da una nuovissima installazione 1.9.2.3 prima di eseguire lo script di patch:

  • app / code / core / Mage / core / Modello / File / Validator / image.php
  • app / code / core / Mage / Vendite / Modello / Quote / Item.php

La patch presuppone che tutte le altre patch di sicurezza siano già state applicate. I file di cui stai parlando sono stati aggiunti / modificati da patch precedenti. Ti manca almeno SUPEE-7405.
Ryan Hoerr,

Ciao Ryan, in effetti ho provato ad applicare anche 7405, ma non ha funzionato neanche ... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52 \ (1) .sh Verifica se la patch può essere applicata / ripristinata correttamente ... ERRORE: Patch non può essere applicata / ripristinata correttamente. (..) Adminhtml / Helper / Sales.php Hunk # 1 FAILED at 121. 1 hunk su 1 FAILED - salvataggio degli scarti nel file (..) Adminhtml / Helper / Sales.php.rej patch file (..) / Core / Model / Config.php Hunk # 1 FAILED at 1642. 1 hunk su 1 FAILED - salvataggio degli scarti nel file (..) Config.php.rej patch file (..) / Quote / Item.php Hunk # 1 FAILED at 509 ....
Ricardo Martins,

@RicardoMartins come posso risolvere questo errore: patch file app / locale / en_US / Mage_Adminhtml.csv Hunk # 2 FAILED at 36. 1 su 2 hunk FAILED - il salvataggio degli scarti nel file app / locale / en_US / Mage_Adminhtml.csv.rej ?
zus

0

Basta un'aggiunta a https://magento.stackexchange.com/a/176930/46249

Si noti che i collegamenti simbolici sono sempre stati disabilitati per impostazione predefinita sulle nuove installazioni di Magento admin SÌ / NO valori di configurazione predefiniti su "NO". L'aggiornamento ora disabilita esplicitamente i collegamenti simbolici in config.xml e come ulteriore precauzione rimuove anche la sezione del modello da admin-> developer che conteneva l'opzione di configurazione.

Ciò non influirà sulle impostazioni correnti del collegamento simbolico, se i collegamenti simbolici attivati ​​manualmente prima della 1.9.3.2 rimarranno abilitati, sebbene non sia più possibile visualizzare l'impostazione in admin.


Il testo in grassetto non è corretto. Se l'aggiornamento a 1.9.3.4 (SUPEE-9767 V2) o le impostazioni correnti più recenti verranno eliminati:

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

Gli amministratori responsabili possono abilitare nuovamente la sezione admin del link simbolico cercando le modifiche alla sezione template in app / code / core / Mage / Core / etc / system.xml e aggiungendo la sezione a system.xml intorno alla riga 600. Oppure i link simbolici doppio controllo sono ancora abilitati con

Rendi nuovamente visibile l'opzione di configurazione non risolve il problema. L'opzione viene visualizzata, ma non è possibile modificare la configurazione poiché il modello di backend appena introdotto impedisce il salvataggio del valore. Vedere:

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

e

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

Quindi devi rimuovere o sovrascrivere questo modello di back-end, vedi Come abilitare i collegamenti simbolici dopo l'installazione di SUPEE-9767 V2?

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.