Correctif de sécurité SUPEE-9767 - Problèmes possibles?


108

Un nouveau correctif de sécurité est disponible pour Magento 1, qui traite 16 problèmes APPSEC: https://magento.com/security/patches/supee-9767.

Sept vulnérabilités ont un score supérieur ou égal à 8.0 pour CVSSv3 Severity et elles sont exploitées à l'état sauvage. Il s'agit donc d'un correctif essentiel. Les sites peuvent appliquer SUPEE-9767 ou mettre à jour la nouvelle version CE 1.9.3.3 / EE 1.14.3.3.

Quels sont les problèmes courants ou les pièges à surveiller lors de l'application de SUPEE-9767?


MISE À JOUR 2017-07-12:

Magento a publié les versions SUPEE-9767 V2 et CE 1.9.3.4 afin de résoudre nombre des problèmes posés par le correctif initial. Si vous avez appliqué la V1, vous devez revenir en arrière puis appliquer la V2. Si vous n'avez pas encore corrigé, appliquez simplement la V2, et la plupart des problèmes évoqués ici ne seront pas pertinents.


"Sept vulnérabilités ont un score supérieur ou égal à 8.0 pour CVSSv3 Severity, et elles sont exploitées à l'état sauvage. Il s'agit donc d'un correctif essentiel." Je voulais juste vérifier que "l'attaquant" a besoin d'entrer dans l'administrateur pour réaliser l'un de ces exploits?
PaddyD

3
oui, vous devez avoir un accès administrateur pour exploiter ...
MagenX

Le correctif ne semble pas arrêter le point de terminaison commun de la force brute (c'est-à-dire / rss / order / new), ce qui semble être le moyen le plus courant que les botteurs tentent d'accéder aux zones administratives?
Ricky Odin Matthews

1
Je l'utilise pour RSS @RickyOdinMatthews dans .htaccess RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC]
Richard Feraro

@RichardFeraro J'utilise nginx, mais j'utilise déjà une solution similaire. J'ai remarqué que les robots recherchent généralement ces points de terminaison et les forcent brutalement.
Ricky Odin Matthews

Réponses:


107

Voici mon aperçu du patch après avoir fouillé dedans

TIME SAVER : Experius fournit un utilitaire de correction qui vous aide à rechercher les fichiers dans des thèmes personnalisés, des modules personnalisés ou des remplacements locaux qu'il peut également être nécessaire de corriger manuellement . Vous pouvez le trouver ici: https://github.com/experius/Magento- 1-Experius-Patch-Helper # magento

Clés de formulaire de commande

Comme indiqué dans l'autre message, ce correctif ajoute des clés de formulaire aux formulaires suivants:

Formulaire de livraison:

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

Formulaire de commande de facturation multiple:

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

Formulaire de commande d'expédition à plusieurs expéditions:

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

Formulaire de commande pour les adresses multiples:

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

Formulaire de facturation:

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

Formulaire de commande d'expédition:

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

Formulaire de paiement:

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

Formulaire de paiement pour la méthode d'expédition:

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

Formulaire de paiement de facturation persistante:

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

De plus, les fichiers JS suivants ont été mis à jour pour être compatibles avec cette modification:

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

Que faire:

Si vous utilisez des versions personnalisées de ces modèles, vous devrez les mettre à jour en y ajoutant le code suivant:

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

Si vous utilisez un module de paiement tiers, vous devrez le contacter afin qu'il puisse fournir une version mise à jour de son module.

De même, si vous disposez de versions personnalisées des fichiers JS précédemment répertoriés, vous devrez également les mettre à jour.

GAGNEZ VOTRE TEMPS :

Fabian Schmengler a écrit un joli petit script pour mettre à jour toutes ces choses pour vous, vous pouvez le trouver ici:

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

REMARQUE IMPORTANTE : la validation de la clé de formulaire de paiement peut être modifiée dans le backend via un nouveau champ de configuration sous Système> Configuration> Admin> Sécurité> Activer la validation de la clé de formulaire à la validation . CECI N'EST PAS ACTIVÉ PAR DÉFAUT , vous devrez donc l'activer pour bénéficier de cette fonctionnalité de sécurité !!! Notez que vous recevrez un avis dans le backend si ce n’est pas activé.

Rappel de téléchargement d'image

Le contrôleur de la galerie d'images a été mis à jour pour ajouter un rappel de validation.

Que faire

Si vous utilisez un module personnalisé qui télécharge une image avec un code ressemblant à ceci:

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

Je vous suggère fortement de mettre à jour ce code en ajoutant l'élément suivant:

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

Liens symboliques

Ce correctif supprime le champ de configuration du système qui vous permet d’autoriser les liens symboliques de modèles dans le backend. Auparavant, il se trouvait sous Système> Configuration> Développeur> Modèle> Autoriser les liens symboliques . Maintenant la section entière de modèle est parti.

De plus, ce champ est maintenant désactivé par défaut via le bouton app/etc/config.xml

La chose amusante ici est que vous obtiendrez un avis dans le backend si ce champ de configuration est activé avant le correctif, mais vous ne pourrez pas le désactiver tant que le champ aura disparu.

La seule façon de le faire est d'exécuter la requête SQL suivante

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

Clarification

Premièrement, je vous suggère fortement de vérifier ces deux publications qui vous aideront à comprendre le but de cette modification Symlink:

Cette modification consiste en fait à appeler du contenu téléchargeable (comme des images) via des directives de modèle.

Le problème lié aux liens symboliques n’est exploitable qu’avec un accès administrateur et Magento a également ajouté une protection supplémentaire contre les téléchargements d’images.

Veuillez noter qu’il existe des protections contre les moyens connus de l’exploiter en plus du paramètre lui-même.

Que faire : si comme moi, vous utilisez modman ou composer avec des liens symboliques modèles, vous rencontrerez des problèmes. J'essaie toujours de savoir quelle est la meilleure chose à faire ici, à part le traitement des requêtes SQL.

Article principal sur ce sujet: SUPEE-9767, modman et liens symboliques

Liste de problèmes possibles

V2 a été publié depuis ce post original. N'oubliez pas de mettre à jour

Bogues

Le mot 'confirmé' est utilisé pour les bogues confirmés. Si ce n'est pas là, cela signifie que cela pourrait être un bogue mais que cela n'a pas encore été confirmé.

Hunk Failed Issues

Notez que tous ces problèmes peuvent être simplement dus au fait que vous avez modifié le fichier d'origine, afin de vérifier que ce n'est pas le cas:

  • Sauvegardez le fichier où vous obtenez l'erreur Hunk Failed
  • Téléchargez le fichier original de votre version de Magento
  • Comparer les deux fichiers

Si les fichiers sont différents, vous devez appliquer le correctif avec le fichier d'origine, puis réappliquer vos modifications personnalisées de manière propre, telles que:

  • modèle personnalisé dans un dossier de thème personnalisé
  • local.xml
  • app / code / fichier local

Si les fichiers ne sont pas différents, il s'agit d'un problème d'autorisation ou d'un "bogue" dans le correctif.


1
@ Icon Nope. Pour vérifier, utilisez l'outil que j'ai cité en haut de ma réponse
Raphael au Digital Pianism

1
Juste pour ajouter à la liste des "autres problèmes": il semble que magento.stackexchange.com/questions/167616/… ne soit pas non plus corrigé dans la dernière version
Anton Boritskiy

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

1
Autre ajout à la liste: le patch rompt le traitement par défaut du thème par défaut magento.stackexchange.com/questions/177681/…
Aad Mathijssen le

1
'Le filigrane a un fond noir lorsqu'il est transparent' - peut confirmer que celui-ci est correct. Cela se produit lorsque vous téléchargez un
fichier

42

Problème 1: clé_formulaire non valide à la caisse une page

Magento ajoute form_keyau maximum des formulaires.

si vous avez using default onepage and using custom theme, alors vous commencerez à obtenir ** form_keyproblème à la caisse à chaque étape **;

vous devriez ajouter la clé de formulaire à <?php echo $this->getBlockHtml('formkey') ?>

former des fichiers d'étape de caisse si les fichiers suivants sortent,

  • 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

si les fichiers de modèle appellent depuis le thème de base, cela ne crée pas de problème. Parce que patch mettra automatiquement à jour ces fichiers.

Notez aussi: <?php echo $this->getBlockHtml('formkey') ?>devrait toujours être à l'intérieur de la balise

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

** Si vous utilisez la commande multi-envois Magento, vous devez le faire à

sous les fichiers:

Issue2: form_key issu du formulaire d’estimation d’expédition à la page de panier:

Ajouter un formulaire à la page d’envoi du devis à la page du panier

Ensuite, il faut ajouter la clé de formulaire <?php echo $this->getBlockHtml('formkey') ?>

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

Problème 3: erreur Magento onepage checkout opcheckout.js

Si vous utilisez la commande par défaut onepage et que vous avez opcheckout.js alors devrait vérifier

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {est disponible sur opcheckout.js

Sinon, remplacez

if (éléments [i] .name == 'payment [méthode]') {

avec

if (éléments [i] .name == 'payment [méthode]' || éléments [i] .name == 'clé_formulaire') {

Dans le cas de issue1, issue2, issue3, le problème peut être facilement résolu en utilisant le script de @FabianSchmengler, add-checkout-form-key.sh . Cela résoudra le problème sur vos fichiers de thèmes réceptifs

Problème 4: clé de formulaire non valide après la connexion du client lors de la réécriture de Mage_Customer_Model_Session

Si la Mage_Customer_Model_Sessionclasse réécrit ou a appelé de

app/code/local/Mage/Customer/Model/Session.phpalors vous pouvez avoir un problème form_key lorsque nous définissons un client pour la session à l'aide de setCustomerAsLoggedIn()/ ou après un client défini à la session.

Dans ce cas, vous devez être ajouter

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

à setCustomerAsLoggedIn () avant l’appel de

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

Problème 5: Problème Form_key après la déconnexion

Après client logout de la session , vous pouvez commencer à numéro de session si Si Mage_Customer_Model_SessionRéécriture de classe ou ont appelé de

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

Dans ces mêmes besoins pour ce cas:

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

Recommandation:

Recommandation 1: pour résoudre le problème de supee-9767 , vous pouvez utiliser le correctif https://github.com/experius/Magento-1-Experius-Patch-Helper.

C'est l'une des meilleures solutions pour le moment.

Notez qu'avant de faire cela, il est fortement recommandé de faire une sauvegarde des fichiers et de la base de données ou une sauvegarde complète du système.


Recommandation 2: Utiliser la fonctionnalité de correctif sur votre ONESTEP CHECKOUT

Nous savons que la version du correctif supee-9767 a été modifiée pour des raisons de sécurité. Si vous utilisez ONESTEP CHECKOUT, vous devez ajouter la validation form_key à l'action SAVE de votre contrôleur de paiement onestep .

Supposons que pour enregistrer les détails de la méthode d’expédition, votre commande onestep utilise saveShippingmethod (). Ensuite, vous devez ajouter

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

Également sur vous devez ajouter une clé de formulaire <?php echo $this->getBlockHtml('formkey') ?> à votre section respective des fichiers phtml à la caisse

Un lien connexe

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


1
One-Liner simple et rapide pour trouver vos fichiers de modèles personnalisés pour la clé de formulaire à la caisse; trouver app / design / frontend | grep -E "paiement / onepage / (facturation | paiement | expédition | méthode_expédition) .phtml" | grep -v "base / default" | grep -v "rwd / default"
Peter Jaap Blaakmeer Le

6
ou les mettre à jour immédiatement avec un peu plus d' une doublure: gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b
Fabian Schmengler

c'est magique @FabianSchmengler !!! :)
Amit Bera

@FabianSchmengler génial, cela a fonctionné!
Peter Jaap Blaakmeer

1
@AmitBera FYI: certains plugins de paiement utilisent AJAX pour soumettre la facturation / l'expédition / etc. Je viens juste d'en patcher un. Un moyen facile de le faire est de mettre <script> var formKey = "<? Php echo Mage :: getSingleton ('core / session') -> getFormKey ();?>"; </ script> dans la tête du thème. Vous pouvez ensuite ajouter form_key: formKey en tant que paramètre de la soumission AJAX. Bien sûr, testez les formulaires après pour confirmer la soumission du nouveau paramètre et modifiez-le pour le gérer comme vous l'avez mentionné dans votre message.
Kalvin Klien

26

Basé sur mon premier passage à la révision du fichier de correctif ...

  • Un nouveau paramètre admin/security/validate_formkey_checkouta été ajouté. Lorsqu'ils sont activés, les formulaires de commande sont vérifiés pour la présence d'une clé de formulaire. Si les fichiers de modèle sont remplacés dans le thème, ils devront être mis à jour à cet emplacement. Ce paramètre semble être désactivé par défaut
  • Les liens symboliques semblent être interdits par défaut (in app/etc/config.xml). En outre, la possibilité de les autoriser semble avoir été retirée de la configuration de l'administrateur. Toutefois, si votre site avait précédemment explicitement activé les liens symboliques, le paramètre serait enregistré dans la base de données, annulant ainsi cette modification.
  • Vous devez effacer le cache ET le cache de page complet lorsque vous appliquez ce correctif. Les exceptions de conception sont enregistrées dans un format incompatible avec le décodage. Vous verrez une erreur comme celle-ci "Echec du décodage: erreur de syntaxe" si vous ne videz pas le cache de la page.

1
Vous pouvez également entrer avec un éditeur hexadécimal et l'ajouter vous-même à la base de données, mais c'est peut-être un peu trop pour la plupart des gens
cat

1
Si certains d'entre vous utilisent CDN, comme cloudflare, veillez à vider le cache. J'ai essayé d'aller à la caisse avec CDN étant actif et cela ne dépasserait pas la page de paiements. Au moment où j'ai purgé le cache et activé le mode Développement, tout s'est bien passé.
Icon

14

Sous le base/defaultfichier concerné par ce correctif, si ces fichiers se trouvaient dans votre thème, apportez les modifications nécessaires.

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

Dans tous les phtmlfichiers ci- dessus , une ligne de clé de formulaire est ajoutée. Veuillez donc ajouter cette ligne dans votre fichier phtml respectif.

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

Pour le numéro ci-dessus, @fabian a créé un script qui ajoutera une clé de formulaire même dans votre fichier de thème.

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

après l'application du correctif de sécurité, si vous obtenez une erreur de clé de formulaire, vous pouvez appliquer ce correctif; pour appliquer ce processus, le processus est identique au correctif de sécurité

  sh filename.sh

et un base/defaultchangement de Jsfichier

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

donc si ce jsfichier est en cours de chargement à partir de votre thème, suivez les étapes ci-dessous

enlever la ligne de coup

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

et ajouter ci-dessous ligne au lieu de ci-dessus

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

MODIFIER

Et si vous utilisez une extension d'extraction qui remplace les fichiers ci-dessous, ajoutez une ligne de clé de formulaire dans le fichier phtml de l'extension d'extraction.

EDIT2 - Problèmes

1) Erreur à saveBillingAction () ou à l'obtention de la clé de formulaire null ou Problème de clé de formulaire: le correctif 9767 obtenant une clé de formulaire non valide

2) Hunk # 1 FAILED à 225. 1 Hunk sur 1 - enregistrer les rejets dans le fichier app / design / frontend / entreprise / default / template / persistent / checkout / onepage / billing.phtml: SUPEE-9767 - Hunk # 1 FAILED à 225. 1 morceau sur 1 a échoué

3) enregistrement des rejets dans le fichier app / code / core / Enterprise / PageCache / Model / Observer.php.rej: SUPEE-9767 ERREUR: le correctif ne peut pas être appliqué / annulé avec succès

4) SUPEE-9767, modman et liens symboliques: SUPEE-9767, modman et liens symboliques

5) app / design / frontend / rwd / default / layout / page.xml Morceau n ° 1 en échec à 36 ans. Morceau n ° 2 en échec à 54 ans. 2 mecs sur 2 ÉCHEC: SUPEE-9767

6) 1 morceau sur 1 ÉCHEC - enregistrement des rejets dans le fichier app / code / noyau / Mage / Ventes / Modèle / Quote / Item.php: Magento 1.9.2.2 Patch SUPEE-9767 ERREUR

7) erreur de vérification onestep (là encore, il s'agit du problème de la clé de formulaire): SUPEE-9767 Magento CE 1.9.3.3 Onestep Checkout ne fonctionne pas avec la validation de clé de formulaire à la caisse activée

8) Problème d' enregistrement du client en une étape: SUPEE-9767 Patch / CE 1.9.3.3 - Contrôle en une page - Problème d'enregistrement du client

9) app / code / core / Mage / Core / Modèle / Fichier / Validateur / Image.php: Échec de Magento SUPEE 9697 1.9.2.2 sur Image.php


1
La version 2 du correctif devrait être disponible bientôt. Les bugs devraient être corrigés.
Icon

1
@icon en attente de la v2
Murtuza Zabuawala

9

Notez que les liens symboliques ont toujours été désactivés par défaut sur les nouvelles installations Magento. Les valeurs de configuration YES / NO de l'administrateur sont définies par défaut sur «NO». La mise à jour désactive maintenant explicitement les liens symboliques dans config.xml et, à titre de précaution supplémentaire, supprime également la section de modèle de admin-> developer contenant l'option de configuration.

Cela n'affectera pas vos paramètres de lien symbolique actuels. Si vous avez activé manuellement les liens symboliques antérieurs à 1.9.3.2, ils le resteront, bien que vous ne puissiez plus voir le paramètre dans admin.

Les utilisateurs qui utilisent modman pour gérer les modules Magento 1.x doivent s’assurer qu’ils ne désactivent pas les liens symboliques, car cela désactive les modules modman.

Les administrateurs responsables peuvent réactiver la section admin de symlink en recherchant les modifications apportées à la section de modèle dans app / code / core / Mage / Core / etc / system.xml et en ajoutant la section à votre system.xml vers la ligne 600. Ou vérifier les liens symboliques sont toujours activés avec

n98-magerun.phar config: dump | lien symbolique grep

Voici le fichier diff pour magento1933 et magento1932 afin de vous aider à identifier les modifications du thème par défaut susceptibles d’affecter vos thèmes personnalisés / étendus.

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


Pourquoi ont-ils supprimé l'option Symlinks?, Existe-t-il maintenant un exploit ouvert au public (en dehors de l'utilisateur administrateur) ou s'agit-il simplement d'un risque s'il se trouve dans un environnement partagé?
PaddyD

ce fil semble répondre à ma question: magento.stackexchange.com/questions/176952/…
PaddyD

Les liens symboliques sont désactivés pour une raison. Je suggère de copier au lieu de lien symbolique: magento.stackexchange.com/a/177149/54863
Barryvdh

9

Problème: L'utilisation de php7 génère parfois l'erreur suivante:

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}

Il est presque certain que la version de Zend doit en faire quelque chose. Une solution rapide est la suivante, mais elle n’est certainement pas correcte:

-> app / code / core / Enterprise / PageCache / Model / Observer.php: 244 remplacez-le par:

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

-> et app / code / core / Enterprise / PageCache / Model / Observer.php: 177 avec:

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

Bien sûr, créez un addon pour réécrire ceci. Mais je suis sûr qu'il y a quelque chose de mieux à faire ici.

UPDATE (Meilleure solution)

-> Allez à: lib / Zend / Json.php et après la ligne 76, ajoutez ceci:

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

Créez votre extension pour la remplacer et ne pas éditer le fichier core.


La mémoire cache était complètement effacée. Ce n'est pas le même problème.
folektoras133

2
Nous sommes confrontés au même problème: revenir sur app / code / core / Enterprise / PageCache / Model / Observer.php a supprimé le problème, mais il ne s'agit évidemment pas du correct correctif, mais simplement de la prévention 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

Problème: le code dynamique ou le code CSS désactive l'élément d'entrée de la clé de formulaire à la caisse.

Un problème que j’ai vu est celui où le code dynamique (paypal plus) dans le processus de paiement d’une page écrase l’ élément fieldset dans le formulaire de méthode de paiement en une étape html - suppression ou désactivation (avec css) de l’élément masqué form_key.

Le correctif consiste à s'assurer que l' élément formkey n'est pas désactivé par aucun code dynamique ou css. Déplacer le code formkey en dehors de l’ élément fieldset peut également aider.

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

Vous pouvez facilement confirmer si la clé_form est détectée et envoyée au contrôleur de page en inspectant les demandes de réseau ajax dans votre navigateur au fur et à mesure que vous avancez dans les méthodes de paiement. Chaque méthode doit inclure la clé de formulaire dans les données de formulaire ajax, si le formulaire la clé n'est pas là, mais le code source de Magento a été corrigé. Vérifiez si du code externe affecte l'élément de la clé de formulaire, c'est-à-dire les modifications css ou dynamiques du côté client.

entrez la description de l'image ici


2
Cette solution ne semblait pas fonctionner pour moi avec EE. J'ai trouvé que le fichier app/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml devait également être mis à jour: les lignes 35 à 38 doivent être mises à jour pour inclure || elements[i].name == 'form_key', avec les autres sélecteurs, le champ de formulaire form_key désactivé.
Greg Nickoloff

Merci g-man1066! C'était exactement le problème que j'avais.
grafikchaos


8

PROBLÈME: L' enregistrement du client échoue lors de l'utilisation de la commande générique Magento en 5 étapes.

Ce problème n'est présenté que lorsque nous ENABLEMENT l'authentification par clé de formulaire. Version utilisée: 1.7.0.2, mais il semble que quelqu'un ait posté le même problème sur la version 1.9.3. SUPEE-9767 Patch / CE 1.9.3.3 - Vérification d'une page - Problème d'enregistrement du client

Lorsque vous passez à la caisse, deux options s'offrent à vous: COMMANDER EN TANT QUE CLIENT OU S'INSCRIRE Une fois que vous avez cliqué sur "Enregistrer", vous devez remplir le formulaire ainsi que le mot de passe pour procéder à toutes les étapes et compléter la commande. La commande est passée, MAIS le client n'est jamais enregistré dans magento. Il ressemble à la commande passée par l'invité.

Lorsque je suis retourné et que l’ authentification de clé de formulaire désactivée a été effectuée et que j’ai essayé de passer commande en enregistrant en tant que client, celle-ci a été placée sans aucun problème et le client s’est enregistré dans le serveur.


1
Voici un article plus détaillé sur ce problème magento.stackexchange.com/questions/177035/…
Raphael au Digital Pianism

8

UPDATE 13/07/2017 [LA QUESTION EST FIXE]

L’équipe de Magento a publié le SUPEE-9767 V2 dans cette version du correctif, le problème avec les fichiers gif et png transparents est résolu.

Vous devez annuler toutes les modifications apportées au fichier traité dans ce fil de discussion. Puis annulez le correctif V1 appliqué et appliquez enfin la nouvelle version V2.


PRE - SUPEE-9767 V2

Veuillez ne pas utiliser le code ci-dessous, mais plutôt appliquer la V2 du correctif. Le problème mentionné ci-dessous est déjà résolu dans cette version.

Si quelqu'un rencontre un problème avec les fichiers png transparents, l'arrière-plan devient noir lorsqu'il est chargé à partir du panneau d'administration. (Sur les produits) est en relation avec le rappel de téléchargement d'image introduit dans:

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

À l'heure actuelle, je ne sais pas exactement ce qui cause ce comportement, mais j'essaie de le comprendre. Je peux confirmer que lorsque le rappel est supprimé, le comportement étrange disparaît.

entrez la description de l'image ici

MISE À JOUR

Ok, j’ai trouvé la fonction également mise à jour à partir de SUPEE-9767, c’est réellement casser la transparence dans les png. Une copie de l’image originale est créée sans transparence.

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

MISE À JOUR

Voici une version mise à jour de la fonction pour préserver la transparence du png

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

ces deux lignes doivent être ajoutées au correctif. Mettre à jour la fonction dansapp/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.'));
}

MISE À JOUR 23/06/17

Cette version mise à jour de la fonction corrige la transparence PNG et 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
Cela a résolu mon problème dans une installation de Magento 1.7. Merci!
Tjitse

Pas de problème Tjitse notera simplement cette modification au cas où l'équipe de Magento ne répare pas le correctif, vous devrez l'inverser lors de la création du prochain correctif. J'ai soumis le problème à la communauté à bugcrowd.com en espérant qu'ils proposeront bientôt des correctifs.
Daniel Yovchev

cela ne le corrige pas pour les pngs, mais pas pour les fichiers gif transparents. Les fichiers gif nécessitent une manipulation légèrement différente avec imagecolortransparent
alternez le

Merci de signaler cette alternance voir la fonction mise à jour qui corrige la transparence gif aussi.
Daniel Yovchev

7

Problème: autoriser la notification des liens symboliques non présentée aux administrateurs

La notification de lien symbolique ne sera pas affichée dans la zone de notification de l'administrateur car elle n'est pas incluse dans la liste. <block type="core/text_list" name="notifications" as="notifications">

Le correctif pour CE et EE ci-dessous:

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

Le problème est </block>à la fin de checkout_formkey(ce qui se termine automatiquement) et donc ferme le parent notifications. Cela fait que le notification_symlinkne soit pas inclus dans le core/text_listet ne soit pas rendu.


Ce n'est pas vraiment un problème, la notification a été supprimée car les liens symboliques ont été explicitement désactivés et la section de configuration de symlink supprimée. Il n'est pas possible de modifier manuellement la valeur du lien symbolique dans admin dans v1933; afficher une notification de l'administrateur est donc plutôt inutile. Le problème se posera pour les nouvelles installations de 1933 où les utilisateurs qui ont besoin de liens symboliques, c’est-à-dire pour modman, ne peuvent plus l’activer manuellement. On pourrait en déduire que Magento ne s'attend pas à de nouvelles installations 1.x ...
mercredi

Je ne suis pas d'accord, ce patch ne désactive pas explicitement la configuration si elle est déjà définie - elle ne la désactive que si elle n'est pas déjà définie. Par conséquent, si une instance a dev / template / allow_symlink défini sur yes dans la base de données / local.xml avant ce correctif et qu'ils appliquent le correctif, ils DEVRAIENT recevoir l'avertissement que les liens symboliques sont autorisés car ils sont potentiellement vulnérables.
mwylde

Je vois ce que vous voulez dire et vous avez raison. Mais pour un utilisateur normal, que feraient-ils alors - il est impossible de le désactiver manuellement de l’administrateur car l’option de configuration a été supprimée. C'est un peu une situation de
piège

7

Petit conseil pour #patchday; Après avoir copié la 1.9.3.3 sur votre installation, lancez-le git diff -w --stat | grep -v " 2 +" | grep -v " 0"pour voir rapidement les plus gros changements dans les fichiers.


7

Problème: le modèle d'expédition EE n'est pas corrigé

J'ai corrigé une installation EE 1.13.1.0 et le modèle d'envoi d'entreprise ( app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) n'a pas été ajouté à la clé de formulaire, mais les modèles de facturation et de paiement l'ont été.

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml a été patché.


J'avais également besoin (pour EE 1.14.2) d'ajouter le form_key à /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtml,.../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml
Greg Nickoloff

4

Il existe un problème avec les versions de Magento EE corrigées avec SUPEE-9767 (donc pas avec les mises à niveau vers 1.14.3.3). La clé de formulaire sur cette page sera mise en cache. Ainsi, lorsque je vide mon cache, puis que je vais sur une page de produit et que je m'assure que la page est complètement mise en cache (rafraîchissez-la plusieurs fois), je devrais pouvoir ajouter ce produit à mon panier.

Maintenant, lorsque j'ouvre un autre navigateur (ou mode incognito), ouvrez la même page et essayez d'ajouter le produit à nouveau au panier. Le produit ne sera pas ajouté au panier, à cause de la clé de formulaire. Désormais, lorsque vous videz à nouveau le cache, le produit peut être ajouté à nouveau au panier.

Merci à Jasper Zeinstra


3

Pour les développeurs utilisant Magento Composer Intaller, vous pouvez modifier la stratégie de déploiement en Copier au lieu de Lien symbolique. Vous pouvez également configurer l’ajout des fichiers de module à votre fichier .gitignore afin que votre référentiel reste propre.

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


Nous avons découvert que la copie "magento-force": true,devient importante
Jeroen


2

Problème: Le correctif fonctionnait sous vanilla Magento 1.7.0.0 [modifié]

Lors des tests de notre script de correctif, nous avons découvert un problème dans le correctif pour Magento 1.7.0.0. Je ne sais pas si quelqu'un l'utilise encore, mais de toute façon, c'est un problème dans SUPEE-9767. Nous avons utilisé une installation vanille et nous avons d’abord installé tous les correctifs précédents.

Fichier Patch utilisé: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh Le fichier patch ne fonctionne pour Magento 1.7.0.1 et 1.7.0.2

Résumé des problèmes:

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

Pour mémoire, ceci sur le 1.7.0.0 nous avons essayé le correctif sur:

$ 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
Si vous manquez ce fichier, vous n'avez probablement pas appliqué le correctif de sécurité SUPEE-7405.
Ryan Hoerr

@RyanHoerr vous avez raison, SUPEE-7405 a été ignoré car le fichier officiel PATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.shne fonctionne pas pour la version 1.7.0.0. J'ai créé une version fixe du fichier. Si quelqu'un en a besoin, envoyez-moi un message.
Commentaires

2

Je devais simplement annuler ce correctif en raison d'un comportement étrange. Pour une raison quelconque, certains utilisateurs ne pouvaient pas ajouter certains articles à leur panier.

Je suppose que cela a quelque chose à voir avec les anciennes offres entrant en collision avec les estimations actuelles de ce client. J'ai vérifié ce problème en me connectant en tant qu'utilisateur pour m'assurer qu'il ne s'agissait pas d'un 1D10T.

C’est un problème depuis que j’ai pris cette vie de patch vendredi dernier. Nous utilisons 1.14.2.4 . Nous sommes fortement modifiés afin que cela puisse fonctionner correctement pour les autres utilisateurs. Juste un avertissement!


C’est exact, le correctif est cassé et ajoute au panier une action pour la version EE de Magento. En gros, le problème provient du fait que le module PageCache possède une version de la logique de génération form_key, alors que la session possède la sienne. Lorsque FPC dispose de la version mise en cache de la page demandée, mais doit régénérer minicart, une session est déclenchée qui régénère la clé_formulaire en même temps que la sauvegarde de FPC est appelée, laquelle génère sa propre clé_formulaire. À ce stade, la valeur de session form_key diffère de celle stockée dans le cookie client (utilisé dans le processeur FPC), de sorte que vous obtenez une clé non valide lors de l'ajout au contrôleur de panier.
Stjepan

Je rencontre aussi ce problème. Je vous ferai savoir si je trouve une solution.
cmtickle

J'ai résolu ce problème, explication ici: magento.stackexchange.com/questions/177942/…
cmtickle

Est-ce que quelqu'un sait si cela est résolu dans SUPEE-9767 v2?
Disciple d'un

2

Problème: boucle de redirection infinie sur 1.6.0.0

Solution rapide

Recherchez les lignes ci-dessous à l'intérieur de la fonction protégée par la méthode _checkBaseUrl ($ request) dans le fichier 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
 ) {  

Changer ces lignes en

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

Après cela, enregistrez le fichier (validez dans votre REPO), videz le cache (supprimez tout ce qui se trouve dans le dossier var / cache) et rechargez votre devanture de magasin. Vous devriez trouver le site chargé sans plus de 302 problèmes de redirection après l'application du correctif SUPEE 9767.

Cause première

La différence de valeur SCHEME entre la demande réelle et l'URI après la redirection. Ex.: La demande actuelle renvoie le schéma HTTP mais le schéma de l'URI peut être HTTPS.

Raisons sous-jacentes possibles

  1. Vous avez probablement une règle de redirection dans le fichier .htaccess pour rediriger toutes les requêtes http vers https. L'utilisateur demande http://votredomaine.com et vous avez peut-être changé le schéma et l'a redirigé vers https: // votredomaine au lieu de http://votredomaine.com qu'il avait réellement demandée.

  2. Les adresses URL de base sécurisée et non sécurisée commencent par https


2

Le BUG CONFIRMÉ "L'enregistrement du client échoue à la caisse" est un peu différent de mon côté.

Si le client choisit de s’inscrire à la caisse, son mot de passe n’est pas correctement enregistré. Le client est créé correctement juste que le mot de passe n'est pas stocké. J'ai détecté cela par le fait que le mot de passe n'était pas indiqué dans le courrier électronique de bienvenue. Les gens ne peuvent pas se connecter à cause de cela aussi.

Correction de bug liée dans SUPEE-9767 Patch / CE 1.9.3.3 - Vérification d'une page - Le problème d'enregistrement du client a également résolu le problème .


2

Quelqu'un peut-il me dire ce que le f ... est-ce s ... pour supee-9767?

entrez la description de l'image ici


1
La version jQuery 1.10.2 est considérée comme vulnérable et signalée par certains scanners PCI. La version 1.12 n'est pas.
Ryan Hoerr

@Detzler StackExchange n'est pas un forum. Si vous souhaitez poser une question, vous devez en poster une et non une réponse à une question.
toon81

1
Ryan Hoerr a posé des questions sur les problèmes soulevés par le correctif. Je lui ai donc annoncé un changement radical, comme vous le voyez sur la capture d'écran. Je ne peux pas expliquer la raison de ce changement. J'ai donc demandé. Alors c'est quoi ton problème?
Detzler

2

Le patch ne fonctionne pas même pour un vanento Magento 1.7.0.2.

martins@martinsmac.local:/var/www/magento1702-original$ ./PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Mage/Admin/Model/Session.php
Hunk #1 succeeded at 109 (offset -29 lines).
patching file app/code/core/Mage/Adminhtml/Block/Checkout/Formkey.php
patching file app/code/core/Mage/Adminhtml/Block/Notification/Symlink.php
patching file app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Date.php
patching file app/code/core/Mage/Adminhtml/Model/Config/Data.php
patching file app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php
patching file app/code/core/Mage/Checkout/controllers/MultishippingController.php
patching file app/code/core/Mage/Checkout/controllers/OnepageController.php
Hunk #1 succeeded at 293 (offset -34 lines).
Hunk #2 succeeded at 313 (offset -34 lines).
Hunk #3 succeeded at 363 (offset -34 lines).
Hunk #4 succeeded at 392 (offset -34 lines).
Hunk #5 succeeded at 431 (offset -34 lines).
patching file app/code/core/Mage/Checkout/etc/system.xml
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/Controller/Front/Action.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 141 (offset -7 lines).
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
patching file app/code/core/Mage/Core/etc/config.xml
patching file app/code/core/Mage/Core/etc/system.xml
patching file app/code/core/Mage/Customer/Model/Session.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Adapter/Zend/Cache.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php
patching file app/code/core/Mage/ImportExport/Model/Import/Uploader.php
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file app/code/core/Mage/Widget/Model/Widget/Instance.php
patching file app/code/core/Mage/XmlConnect/Helper/Image.php
patching file app/design/adminhtml/default/default/layout/main.xml
patching file app/design/adminhtml/default/default/template/notification/formkey.phtml
patching file app/design/adminhtml/default/default/template/notification/symlink.phtml
patching file app/design/adminhtml/default/default/template/page/head.phtml
patching file app/design/frontend/base/default/template/checkout/cart/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/billing.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/billing.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/payment.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml
patching file app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml
patching file app/etc/config.xml
patching file app/locale/en_US/Mage_Adminhtml.csv
patching file app/locale/en_US/Mage_Core.csv
patching file app/locale/en_US/Mage_Dataflow.csv
patching file downloader/Maged/Connect.php
patching file downloader/Maged/Controller.php
Hunk #1 succeeded at 400 (offset -5 lines).
Hunk #2 succeeded at 923 (offset -5 lines).
patching file downloader/Maged/Model/Session.php
Hunk #2 succeeded at 235 with fuzz 2 (offset -13 lines).
patching file js/varien/payment.js
patching file skin/frontend/base/default/js/opcheckout.js

même après avoir appliqué manuellement les anciens correctifs.

$ 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 solution / le problème que j'ai trouvé est que certaines des modifications apportées au correctif pour 1.7.0.2 concernent des fichiers qui n'existaient pas avant la 1.9.2.3. J'ai donc copié les fichiers suivants d'une toute nouvelle installation 1.9.2.3 avant d' exécuter le script de correctif:

  • app / code / core / Mage / Core / Modèle / Fichier / Validateur / Image.php
  • app / code / core / Mage / Sales / Model / Quote / Item.php

Le correctif suppose que tous les autres correctifs de sécurité ont déjà été appliqués. Les fichiers dont vous parlez ont été ajoutés / modifiés par les correctifs précédents. Vous manquez au moins SUPEE-7405.
Ryan Hoerr

Bonjour Ryan, En fait, j'ai aussi essayé d'appliquer le 7405, mais cela n'a pas fonctionné non plus ... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52 \ (1) .sh Vérifier si le correctif peut être appliqué / annulé avec succès ... ERREUR: le correctif ne peut pas être appliqué / annulé avec succès. (..) Adminhtml / Helper / Sales.php Hunk # 1 FAILED à 121. 1 morceau sur 1 FAILED - enregistrement des rejets dans un fichier (..) Adminhtml / Helper / Sales.php.rej patcher le fichier (..) / Core / Model / Config.php Hunk # 1 ÉCHEC à 1642. 1 Hunk sur 1 - Enregistrer les rejets dans un fichier (..) Fichier de correction Config.php.rej (..) / Quote / Item.php Hunk # 1 ÉCHEC à 509 ....
Ricardo Martins

@RicardoMartins, comment puis-je résoudre ce problème: correction du fichier app / locale / en_US / Mage_Adminhtml.csv Hunk # 2 FAILED à 36. 1 échec sur 2 mecs FAILED - enregistrement des refus dans le fichier app / locale / en_US / Mage_Adminhtml.csv.rej ?
zus

0

Ajouter un ajout à https://magento.stackexchange.com/a/176930/46249

Notez que les liens symboliques ont toujours été désactivés par défaut sur les nouvelles installations Magento. Les valeurs de configuration YES / NO de l'administrateur sont définies par défaut sur «NO». La mise à jour désactive maintenant explicitement les liens symboliques dans config.xml et, à titre de précaution supplémentaire, supprime également la section de modèle de admin-> developer contenant l'option de configuration.

Cela n'affectera pas vos paramètres de lien symbolique actuels. Si vous avez activé manuellement les liens symboliques antérieurs à 1.9.3.2, ils le resteront, bien que vous ne puissiez plus voir le paramètre dans admin.


Le texte en gras n'est pas correct. Si vous effectuez une mise à jour vers la version 1.9.3.4 (SUPEE-9767 V2) ou si des paramètres plus récents sont supprimés:

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

Les administrateurs responsables peuvent réactiver la section admin de symlink en recherchant les modifications apportées à la section de modèle dans app / code / core / Mage / Core / etc / system.xml et en ajoutant la section à votre system.xml vers la ligne 600. Ou vérifier les liens symboliques sont toujours activés avec

Rendre l’option de configuration visible à nouveau ne résout pas le problème. L'option apparaît, mais vous ne pouvez pas modifier la configuration car le nouveau modèle de backend empêche la sauvegarde de la valeur. Voir:

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

et

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

Vous devez donc supprimer ou remplacer ce modèle principal, voir Comment activer les liens symboliques après l'installation de SUPEE-9767 V2?

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.