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.

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:

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

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

• L'enregistrement du client échoue à la caisse. CONFIRMED & FIXED IN V2
• Bogue PHP7 et EE CONFIRMÉ
• Bug avec les exceptions EE, FPC et Design CONFIRMED
• Ajouter au panier et bug de cookie dans EE CONFIRMED
• Multishipping cassé après le correctif CONFIRMÉ
• Correction d'un bug danshead-simple.phtml CONFIRMED & FIXED IN V2
• L’avertissement Admin Symlink n’est pas affiché sur 1.9.2 CONFIRMED & FIXED IN V2
• Le filigrane devient un fond noir lorsqu'il est transparent. CONFIRMED & FIXED IN V2
• Impossible de mettre à niveau via Magento Connect
• Boucle de redirection infinie sur 1.6.0.0

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.

• patcher le fichier app / design / frontend / rwd / default / layout / page.xml Hunk # 1 FAILED à 36.
• correction du fichier app / design / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtml Hunk # 1 FAILED à 225.
• patcher le fichier app / code / core / Enterprise / PageCache / Model / Observer.php Hunk # 6 FAILED à 1093.
• correction du fichier app / code / core / Mage / Core / etc / system.xml Hunk # 3 FAILED à 13h55.
• patcher le fichier app / code / core / Mage / Sales / Modèle / Quote / Item.php Hunk # 1 FAILED à 500.
• Hunk a échoué le 1.8.0.0

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/

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.

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

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

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.

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.

Problème: Correctifs manquants dans head-simple.phtml

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

besoin des mêmes corrections que

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

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.

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.

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

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.

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.

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

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

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

J'ai eu un problème sur EE 1.14.2.2 avec FPC activé et ce correctif appliqué.

De manière intermittente, les utilisateurs ne pouvaient pas ajouter au panier.

Explication et correction ici: Problème SUPEE-9767 : Problème lié au panier, Problème de cache de page complet pour entreprise

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

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!

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

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 .

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

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

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?