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

Le dernier correctif de sécurité Magento 1, SUPEE-8788, contient 17 mises à jour APPSEC . Il est donc très important de l’appliquer dès que possible. D'autre part, il existe de nombreuses ruptures de compatibilité ascendante potentielles, et compte tenu de l'historique des correctifs au cours de la dernière année, je ne l'appliquerais pas négligemment.

La bonne chose est que cette fois-ci, il n'y a pas de modèles frontaux impliqués, il semble donc que nous n'avons pas besoin de corriger tous nos thèmes. Ceci n'est vrai que pour Magento 1.8 ou supérieur.

Néanmoins: avez-vous rencontré des problèmes de compatibilité ou des bogues après l'application du correctif?

Notes IMPORTANTES

Veuillez noter que 1.9.3 est différent de 1.9.2.4 + SUPEE-8788. Voici le diff entre les deux: https://gist.github.com/digitalpianism/14a15cd52baede0e5d600e8c653f33e9

Mise à jour du 14 octobre: ​​la v2 du correctif a été publiée (voir ci-dessous) Depuis le 13 octobre, les correctifs de 1.5.x à 1.8.x ont été retirés du site Web de Magento en raison de leur incompatibilité avec les correctifs précédents (voir ci-dessous):

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

V3 du patch

Cette nouvelle version est uniquement pour Magento EE 1.13.0.x

Appliquez la V3:

• revenir SUPEE 1533 (si installé)
• installer SUPEE 3941 (si non installé)
• installer SUPEE 8788 v3

V2 du patch

Appliquez la V2:

• revenir SUPEE 8788 v1
• revenir SUPEE 1533 (si installé)
• installer SUPEE 3941 (si non installé)
• installer SUPEE 8788 v2

DemacMedia a développé un script bash utile pour automatiser le processus ci-dessus. Vous pouvez le trouver ici: https://github.com/DemacMedia/magento-SUPEE8788-patcher

Détails du patch

Après avoir approfondi le patch, voici les parties intéressantes (patch du 1.9.2.4):

• Mage_Adminhtml_Block_Media_Uploadera été remplacé par Mage_Uploader_Block_Multipleun Mage_Uploadermodule complet qui supprime la prise en charge de Flash . L'ancien bloc est maintenant obsolète et étend le nouveau bloc.
• Toujours en ce qui concerne le programme de téléchargement, le Mage_Downloadablemodule a été repensé pour prendre en charge le nouveau programme de téléchargement non flash. Il utilise Mage_Uploader_Block_Singlecomme bloc de téléchargement au lieu d'utiliser des modèles.
• Suite à ce changement, t - il des fichiers SWF skin/adminhtml/default/default/media/flex.swf, skin/adminhtml/default/default/media/uploader.swfet skin/adminhtml/default/default/media/uploaderSingle.swfont été supprimés.
• Contrôleur de suppression d'adresses est maintenant protégé par clé de forme directement via getDeleteUrldeMage_Customer_Block_Address_Book
• Contrôleur de suppression de liste élément est maintenant protégé par clé de forme via getRemoveUrldeMage_Wishlist_Helper_Data
• La méthode de paiement Paypal Express garantit désormais que le courrier électronique du client utilisé existe dans Magento lors de la validation et de l'enregistrement d'un nouvel utilisateur. (comprendre: le nouvel utilisateur est créé avant le traitement du nouveau devis)
• Les méthodes de paiement utilisant le client cURL / HTTP ont maintenant la valeur CURLOPT_SSL_VERIFYHOST2 (auparavant 0) et l' CURLOPT_SSL_VERIFYPEERindicateur est maintenant ajouté aux appels cURL. L’option Vérifier l’homologue peut être activée / désactivée via la configuration du mode de paiement via la liste déroulante Activer la vérification SSL.
• Mage_Http_Client_Curla maintenant la valeur CURLOPT_SSL_VERIFYPEERtrue (était false auparavant) , méfiez-vous si vous utilisez un module personnalisé.
• Les dimensions maximales des images de produits sont maintenant configurables dans la configuration. NB: cela peut entraîner un drôle de message d'erreur si vous téléchargez des images trop grandes: format de fichier interdit dans Magento 1.9.2.2 après l'envoi du correctif

Problèmes connus de SUPEE-8788 v2

• Magento 1.9.2.0 SUPEE-8788 v2 Hunk # 1 ÉCHEC à 91 après avoir annulé SUPEE-1533
• Le correctif ne peut pas être appliqué sur le modèle PayPal Express: Magento 1.9.2.2 SUPEE-8788 v2 Hunk # 1 FAILED
• Coïncidence non liée au patch Les courriers électroniques ont cessé d’être envoyés le 1.8: https://magento.stackexchange.com/q/141799/2380 et problème avec le correctif de sécurité 8788 V2
• Modification incompatible en getConfig()amont lors de l'appel de la méthode à partir du bloc de téléchargement: problème dans le Panneau d'administration après l'installation de SUPEE Patch 8788

Problèmes connus de SUPEE-8788 v1

• Mise à jour: la v2 du correctif corrige ce problème (voir ci-dessus)Conflit entre SUPEE-1533 et SUPEE-8788 , solution de contournement possible (hacky) ici . Une solution moins astucieuse ici
• Mise à jour: la version 2 du correctif corrige ce problème Unsupported data type Nerreur dans /lib/Unserialize/Reader/ArrValue.phples versions 1.9.1.0 et peut-être antérieure lorsque le correctif est appliqué. réparer ici: https://gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
• Mise à jour: la v2 du correctif corrige ce problème Conflit possible avec SUPEE-3941: https://magento.stackexchange.com/a/140696/2380
• Problème avec OS X:Illegal Byte Sequence : SUPEE-8788 sur OSX - séquence d'octets illégale
• Correctif mal formé (probablement dû à la séquence binaire du correctif) : correctif pour Magento 1.9.2.4, correctif SUPEE-8788 à la ligne 5790
• Inclusion d'un test_oauth.phpfichier avec le correctif EE , ne poussez pas ce fichier dans prod
• Problème de connexion possible sur EE lié àEnterprise_Pci : https://magento.stackexchange.com/a/140577/2380
• Problème si vous modifiez le fichier de correctif car il contient des fichiers binaires encapsulés , utilisez cette méthode si vous devez modifier: https://magento.stackexchange.com/a/140575/2380
• Dans le cas où vous avez une app/code/localversion Mage/Core/functions.phpvous aurez problème avec la nouvelle hash_equalsfonction : https://magento.stackexchange.com/a/140664/2380
• Il est bon de savoir que certains modèles ont été modifiés en ce qui concerne form_key pour Magento avant la version 1.8.
• Problème possible sur la version 1.5.1.0 avec downloader/Maged/View.php: Le correctif de sécurité SUPEE-8788 a échoué dans le programme de téléchargement / Maged / View.php (M1 v1.5.1.0)
• Si vous avez supprimé / renommé le downloaderdossier: https://magento.stackexchange.com/a/140631/2380

Problèmes connus de 1.9.3.0

Edit: comme la liste est de plus en plus longue et qu’elle est plutôt hors sujet dans cette réponse (car elle n’est pas liée au SUPEE-8788), vous pouvez vous reporter à ce message pour obtenir la liste des problèmes connus de 1.9.3.0: https: //magento.stackexchange. com / a / 140826/2380

En appliquant le correctif, cette erreur peut se produire:

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

Le correctif 8788 contient un contenu binaire. Comme Magento ne fournit aucun lien de téléchargement direct (je déteste cette politique depuis), vous devez télécharger le correctif sur votre ordinateur et le télécharger avec une application de transfert de fichier (comme WinSCP sous Windows) sur votre serveur. WinSCP, par exemple, chargera en mode texte (WinSCP gère les fichiers * .sh sous forme de texte par défaut).

La solution consiste donc à compresser le fichier de correctif avec zip / tar et à décompresser / décompresser à nouveau sur le serveur. et voilà.

Désolé je n'avais aucun moyen de répondre à cette question

1. Téléchargez la version correcte de magento (par exemple: CE 1.9.1.0)
2. Remplacer les fichiers suivants par l'emplacement téléchargé

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

3. Exécuter le patch

A travaillé pour moi

Si vous avez déjà appliqué SUPEE-1533, le correctif échouera app/code/core/Mage/Adminhtml/controllers/DashboardController.php.

J'ai résolu ça par ...

1. Annulez manuellement les modifications apportées à ce fichier par SUPEE-1533
2. Appliquer SUPEE-8788
3. Réintroduire manuellement les modifications apportées à ce fichier par SUPEE-1533

Supprimer le changement du SUPEE-8788 est dangereux car le fichier de correctif contient des données binaires et son enregistrement dans un éditeur peut poser des problèmes (un autre problème).

Voici un résumé de ce que moi (et d'autres) avons rencontré jusqu'à présent. J'essaie de le garder en ordre, n'hésitez pas à ajouter ou à relier tout ce qui manque, cet article est un wiki de la communauté:

Raisons de l'échec du correctif

Si vous voyez "ERREUR: le correctif ne peut pas être appliqué / rétabli avec succès", recherchez "Hunk # 1 FAILED" dans les messages du journal pour vérifier à quel fichier le correctif a échoué.

• Apparemment, la version 2 du correctif pour Magento 1.7 s'attend à ce que SUPEE-3941 soit présent, bien qu'il n'existe que pour Magento 1.8 et 1.9 . Si vous êtes sur Magento 1.7 et voyez des erreurs liées aux fichiers downloader, téléchargez SUPEE-3941 pour 1.8 et appliquez-le sur 1.7, cela devrait fonctionner. Voir le fil de commentaire ici: problème de correctif de sécurité SUPEE 8788

• Sur les versions de Magento auxquelles SUPEE-1533 a déjà été appliqué, le correctif échoue app/code/core/Mage/Adminhtml/controllers/DashboardController.phpcar le fichier est affecté par les deux correctifs et SUPEE-8788 (à tort!) Suppose que la version non corrigée est présente. Ceci est toujours vrai avec la version 2 du patch! La version 2 inclut les modifications apportées à SUPEE-1533. Par conséquent, si vous l'avez déjà installée auparavant, vous devez toujours la restaurer, mais vous n'avez pas à l'appliquer manuellement par la suite.

• Si vous avez supprimé ou renommé le répertoire "téléchargeur", le correctif échouera car il corrige un fichier dans le téléchargeur. La solution la plus simple consiste à restaurer le répertoire d'origine du téléchargeur, à appliquer le correctif, puis à supprimer le répertoire à nouveau. Vous pouvez également supprimer les instructions downloader/lib/Mage/HTTP/Client/Curl.phpdu correctif.

• Les autres messages "Hunk FAILED" sont généralement dus à des modifications de fichiers principaux ou à l'absence de correctifs antérieurs. Assurez-vous que tous les correctifs précédents pour votre version de Magento sont installés et que vous n'avez pas modifié les fichiers principaux.

• Un autre problème courant est que le correctif ne parvient pas à supprimer les .swffichiers en raison de leur contenu binaire. L'erreur ressemblera à ceci:

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

  ou comme ça

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

  ou comme ceci:

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

  Les solutions possibles sont données dans cette réponse par @infabo. Le téléchargement du correctif directement sur le système sur lequel je souhaite l'appliquer, en utilisant curl comme expliqué dans https://gist.github.com/piotrekkaminski/9bc45ec84028611d621e, a toujours fonctionné pour moi, sauf lorsque je l'ai essayé sur Cygwin.

Méthode avancée pour traiter les correctifs ayant échoué: @PeterOCallaghan a suggéré de commenter la ligne d'essai et de traiter manuellement les fichiers * .rej. De cette façon, le correctif peut être partiellement appliqué et s'il ne parvient pas à supprimer les fichiers swf, vous pouvez le faire manuellement. Ou si la mise à jour des fichiers échoue downloaderparce que vous avez supprimé ce répertoire, vous pouvez simplement l'ignorer.

1. vi PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh(ou un nom de fichier similaire) change _apply_revert_patch dry-runpour ressembler à #_apply_revert_patch dry-run

2. exécuter le correctif en publiant ./PATCH_SUPEE-8788_CE_1.8.1.0_v1-2016-10-11-06-54-44.sh

Cela corrigera vos fichiers

3. Commentaire _apply_revert_patchà#_apply_revert_patch

4. exécutez à nouveau le correctif pour ajouter l' app/etc/app/etc/applied.patches.listentrée

5. grep pour tous les fichiers .rej avec

   git status | grep *.rej

6. travailler manuellement dans ces changements

Problèmes après l'application du correctif

Clés de formulaire

• Pour les versions de Magento antérieures à la version 1.8, des modifications ont été apportées aux frontend/base/defaultmodèles. Assurez-vous que vous appliquez manuellement les mêmes modifications dans votre thème s'il remplace ces fichiers.

  Plus spécifiquement, une clé de formulaire a été ajoutée pour les actions frontales telles que:

  • Supprimer un élément de la liste de souhaits
  • Suppression d'une adresse client de la vue du magasin
  • Mise à jour d'un article de devis dans votre panier

  Voir cette réponse de @LukeRogers si vous rencontrez des problèmes avec ces actions.

Téléchargeur personnalisé

Unirgy_Rapidflow et d'autres extensions avec des formulaires de téléchargement personnalisés ne fonctionnent plus.

Voir la réponse de @mpchadwick et le commentaire de @lloiacono

Je l' ai fixé par le remplacement $this->getUploader()->getConfig()avec $this->getUploader()->getUploaderConfig()deUnirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload

Pour savoir si l'une de vos extensions l'utilise, vous pouvez exécuter les opérations suivantes sur la ligne de commande:

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

Messages d'erreur signalés

• Erreur irrécupérable PHP: appel de la fonction indéfinie hash_equals ()

  qui se passe si vous êtes sur une version de PHP avant 5.6 et passer outre code/core/Mage/core/functions.phpà code/local/Mage/core/functions.php( ce qui pourrait être le cas si vous utilisez des extensions Fishpig). Voir cette réponse de @ClaudiuCreanga

Problèmes résolus dans la v2 du correctif

Si vous rencontrez l'un de ces problèmes, vous utiliserez probablement la version 1 du correctif ("v1" dans le nom du fichier). Téléchargez à nouveau le correctif pour obtenir "v2" qui résout ces problèmes:

• Un problème de compatibilité avec SUPEE-3941 et downloader/lib/Mage/HTTP/Client/Curl.php

• "Exception" avec le message "Type de données non pris en charge N" dans /lib/Unserialize/Reader/ArrValue.php

• Le correctif pour EE 1.14.2.0 contenait accidentellement un nouveau fichier test_oauth.php que vous devez supprimer! Voir cette réponse de @MatthiasZeis

Si vous obtenez

Call to undefined function hash_equals() error

même si votre correctif a réussi, cela peut vouloir dire que vous avez copié functions.php dans app/code/local/Mage/Core.

Vous devrez également insérer cette fonction car ce fichier écrase le fichier principal.

Alors insérez app/code/local/Mage/Core/functions.phpà la fin:

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

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

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

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

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

        return 0 === $result;
    }
}

Dans PATCH_SUPEE-8788_EE_1.14.2.0_v1-2016-10-10-02-27-03.sh, un fichier test_oauth.phpest créé dans le répertoire racine de Magento. Vous voudrez supprimer celle-ci (ou du moins ne pas la déployer en production) car elle pourrait exposer une trace complète de la pile des exceptions à la personne qui appelle l'URL https: //thedomain.tld/test_oauth.php .

CECI S'APPLIQUE AUX VERSIONS 1.7 MAGENTO.

Si vous exécutez la version 1.7.0.2 de SUPEE 8788, la version 2 échouera sur la ligne 372 en essayant d'appliquer les modifications suivantes Curl.php:

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

Les instructions indiquent que nous devrions inverser SUPEE-1533 et installer SUPEE-3941.

PROBLÈME: SUPEE-3941 est uniquement disponible pour Magento CE 1.8-1.9. Vous pouvez essayer de l'appliquer pour 1.7, et cela s'appliquera. je pensedéveloppeurs de correctifs Magento devrait publier une version 3 de SUPEE-8788 pour les utilisateurs de magento inférieurs à 1.8 ou créer un patch supplémentaire pour SUPEE-3941 conçu pour la version inférieure à 1.8.

Btw version 1 de SUPEE-8788 n'a pas eu l' Curl.phperreur sur 1.7.0.2 (je l'ai testé sur de nombreuses installations)

Conseil: si vous faites face à des erreurs .swf à la fin, assurez-vous de compresser votre correctif, de les télécharger sur le serveur et de les décompresser. L'erreur SWF disparaîtra.

MISE À JOUR:

Magento a déclaré que, fondamentalement, il est correct d'installer le correctif SUPEE-3941 sur une version de Magento 1.7.0.2 afin d'éviter les erreurs lors de l'application de SUPEE-8788.

Original DashboardController.php (1.7.0.2- Non paché, frais de magento)

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

1533 Patched DashboardController.php contient la modification suivante

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

Le correctif 8788 apporte la modification suivante dans DashboardController.php

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

Comme vous pouvez le voir, 8788 a un changement modifié par rapport à 1533, je ne suis pas sûr de son idéal pour modifier le fichier comme le suggère mpchadwick, en remplaçant manuellement les changements par 8788 par 1533 après avoir installé 8788. Supprimez essentiellement les changements par 8788.

Aucune suggestion?

La moitié tenté de signaler cet article comme étant principalement basé sur l'opinion ou sans réponse claire;)

Des clés de formulaire ont été ajoutées à quelques contrôleurs. Leur nombre varie en fonction de la version de votre magento.

Si vous rencontrez des problèmes

• Supprimer un élément de la liste de souhaits
• Suppression d'une adresse client de la vue du magasin
• Mise à jour d'un article de devis dans votre panier

Vous devrez vérifier votre .phtmlfichier de thèmes et vous assurer de bien POSTcontrôler le paramètre de clé de formulaire pour qu'il passe le contrôle des actions du contrôleur, telles que:

class Mage_Checkout_CartController extends Mage_Core_Controller_Front_Action

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

Ces problèmes ont fait trébucher beaucoup de personnes dans les patchs précédents. Les thèmes personnalisés avec des modèles remplacés sont facilement oubliés lors de l’application des patchs.

Les clés de formulaire sont souvent ajoutées au .phtmlmodèle contenant le formulaire comme un extra inputcomme

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

J'ai rencontré le même problème en swf en 1.9.2.4.

Fox fixe - S'il vous plaît suivez les étapes ci-dessous.

Étape 1. Téléchargez le fichier de correctif de sécurité 8788 SSH sur ce lien: - https://magento.com/tech-resources/downloads/magento/

Étape 2. Après le téléchargement du fichier de correctif de sécurité 8788 SSH, veuillez le placer dans un dossier et créer le même fichier Zip.

Étape 3. Veuillez télécharger le dossier Zip dans le dossier racine Magento et décompressez-le via SSH Putty.

Étape 4. Exécutez le correctif: - $ bash PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh

* Remarque: le fichier de correctif contient des fichiers binaires entiers au format texte. C’est pourquoi, lorsque vous téléchargez un fichier de correctif de sécurité 8788 SSH sans fichier zip, le même fichier est corrompu. *

Après avoir appylé SUPEE-8788, je ne pouvais plus charger les profils "Importer" avec Unirgy_RapidFlow 2.0.0.18, ce qui provoquait une erreur 500 (rien dans les journaux Apache ou HTTPD).

Je suis toujours en train de déboguer et de résoudre le problème avec Unirgy, mais il semble que le blocage du programme de téléchargement cause le problème ( Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload).

Le correctif a introduit plusieurs modifications dans Mage_Adminhtml_Block_Catalog_Product_Helper_Form_Gallery_Contentle parent.

En plus de uRapidFlow, d’autres modules tiers permettant le téléchargement de fichiers peuvent tomber en panne à la suite de SUPEE-8788.

J'ai reçu le message suivant lors de l'exécution du script de correctif:

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

Je pense que c'est parce que j'ai renommé le dossier "downloader", en suivant les recommandations de https://www.magereport.com .

J'ai temporairement renommé le dossier "téléchargeur", appliqué correctement le correctif, puis son nom secret.

Le correctif sur la version 1.9.0.0 échoue également (probablement de la version 1.8.0.0 à la version 1.9.0.1 concernée) en raison de SUPEE-3941. 3941 correctifs téléchargeur / lib / Mage / HTTP / Client / Curl.php et maintenant le 8788 échoue.

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

Solution de contournement pour 1.9.0.1 ci-dessous. Les modifications sont trop approfondies, vous devrez peut-être ajuster le correctif 8788 lui-même.

edit: édite le patch, recherche Curl.php et remplace

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

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

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

avec

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

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

Voici ce que je reçois

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

On dirait que Magento publiera une version mise à jour du SUPEE 8788, afin de corriger la compatibilité avec SUPEE 1533. Je ne suis pas sûr que ce soit une bonne idée d’appliquer les correctifs manuellement pour le moment. Les modifications manuelles peuvent compromettre les futures mises à jour de correctifs. J'aimerais entendre vos pensées.

Cela a été confirmé par Magento Community Manager. À compter du 13 octobre, à 15 h 00, tous les correctifs des versions inférieures à 1.9 sont supprimés de la liste de téléchargement https://www.magentocommerce.com/download?_ga=1.236497153.1889606568.1445610645 Voir l'article: https://community.magento.com/t5 / Correctifs de sécurité / SUPEE-8788-AND-SUPEE-1533-Incompatible-Hunk-error / mp / 50514 / highlight / false # M1805

Nous recevons des rapports sur les nouveaux problèmes suivants que je ne vois pas dans d'autres messages:

• Exception dans les nouvelles versions dans certains cas - appel de la méthode addCrumbs () (dans le cas où getStoreConfig (web / default / show_cms_breadcrumbs) n'est pas défini). Ne devrait pas affecter le correctif, seule la version 1.9.3 / 1.14.3

"Exception" avec le message "Type de données non pris en charge N" dans /lib/Unserialize/Reader/ArrValue.php dans 1.9.1.0 et éventuellement dans des versions antérieures lorsqu'un correctif est appliqué. résolu dans le patch version 2.

Il n'y a actuellement aucune solution de contournement facile connue pour ces problèmes. Nous travaillons à les résoudre dans une nouvelle version du correctif.

Uploader se casse lorsque vous téléchargez le même fichier pour des exemples et des liens simultanément pour des produits téléchargeables. Notez que cela ne se produit que si vous utilisez le même fichier dans les deux zones. (Avant, cela fonctionnait correctement.)

Pour reproduire, éditez un produit téléchargeable et cliquez sur l' onglet Informations téléchargeables :

1. Ouvrez la ligne Samples de l'accordéon et recherchez un exemple de fichier.
2. Sur la rangée Liens de l'accordéon, recherchez un lien de téléchargement.
3. Cliquez sur Upload Files from dans la section Links.

Le programme de téléchargement télécharge le fichier exemple à la place du fichier de lien téléchargeable. Le fichier que vous avez consulté dans la section des liens téléchargeables disparaît.

J'ai pu reproduire cela sur une installation corrigée de la version 1.7.0.2 CE de vanilla.

Oui, j'ai rencontré un autre problème lors de la connexion, il retournera toujours ceci:

J'ai trouvé que c'est parce que sur la ligne 165 de la classe Enterprise_Pci_Model_Observer,

Au lieu de:

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

Cela corrigera:

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

Etant donné que je n'aime pas changer de noyau (même passer au local), mieux vaut que Magento répare ou clarifie cela. Pour le moment, le mien crée de nouvelles extensions pour étendre cela et créer une fonction pour getPassword () (puisque je veux être sûr que tous les développeurs utilisent le mode développeur).

Modification du fichier de correctif

Si quelqu'un doit éditer le fichier de correctif, vous ne devriez pas le faire dans un éditeur, car cela endommagerait les fichiers binaires encapsulés dans le correctif.

Si vous avez une ligne de commande à portée de main, par exemple. linux / * unix essayez d’utiliser un sedutilitaire pour supprimer des lignes spécifiques.

Les accessoires à @fooman pour le tuyau. Voir son essence originale

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

Cela supprimera les lignes 101 à 111 inclusivement.

Problèmes de soumission de formulaire.

Si vous voyez ce qui est mentionné ci-dessus, vous pouvez également:

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

Pour plus d'informations, consultez ce message Qu'est- ce que getBlockHtml ('formkey')?

CE 1.6.2.0 & SUPEE-3941

Pour appliquer le correctif de sécurité SUPEE-8788 (version 2), ( http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html#apply-8788-new ), nous vous suggérons d’appliquer d'abord SUPEE-3941. .

Cependant, sur la page de téléchargement du correctif, il n'y a pas de correctif SUPEE-3941 pour CE 1.6.2.0. Le correctif est disponible uniquement pour CE 1.8 et 1.9.

Comme mentionné dans ce fil de discussion, il semble correct d'appliquer le correctif SUPEE-3941 disponible (pour CE 1.8 et 1.9) à CE 1.7.

Peut-on aussi appliquer SUPEE-3941 (pour CE 1.8 et 1.9) sur CE 1.6.2.0? J'ai essayé de l'appliquer sur CE 1.6.2.0 et j'ai eu l'erreur suivante:

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

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

Un peu tard mais nous avons trouvé un problème dans le correctif SUPEE-8788 V2 qui s’applique au moins aux fichiers de correctif pour Magento 1.7.0.2 et 1.7.0.1. Cela s'applique probablement également à toutes les versions antérieures pour lesquelles une version de correctif existe. Les versions de Magento à partir de la version 1.8 ne sont pas concernées car le correctif ne modifie pas les modèles pour ceux-ci.

En détail

Il manque un formulaire pour le fichier dans le correctif app/design/frontend/base/default/template/persistent/checkout/onepage/login.phtml

Sans cette connexion, la connexion ne fonctionne pas à la caisse (elle ne fonctionne pas sans erreur).

Réparer

Un formkey doit être inséré comme dans le patch suivant:

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

Pour 1533 Patched site, remplacez simplement la ligne ci-dessous de PATCH_SUPEE-8788 *****. Sh:

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

par:

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

Fondamentalement, il vient de retourner le 1533 et laissé 8788 le long.

La capture Authorize.net est interrompue après l’application du correctif. L'autorisation fonctionne bien, mais lors de la saisie du paiement sur la facture, le message "Erreur de la passerelle: le numéro de carte de crédit est requis" . Le fichier journal des paiements indique que la x_typevaleur param passe auth_capturemaintenant, mais elle fonctionnait bien avant le correctif utilisé auparavant prior_auth_capture. Toute personne rencontrant ce problème?

UPDATE: Correctif pour ce problème - Authorize.net ne capture pas

J'ai patché une copie de Magento 1.9.2.4 en utilisant SSH avec SUPEE-8788 J'ai patché une autre copie de Magento 1.9.2.4 en utilisant ftp avec SUPEE-8788 J'ai patché une copie de magento 1.9.1.0 en utilisant SSH avec SUPEE-8788 J'ai utilisé une nouvelle copie de magento 1.9.3.1

Sur tous ces sites Web magento avec SUPEE-8788, je rencontre le même problème (peut-être un bogue du correctif)

Utiliser des produits téléchargeables et aller dans Informations téléchargeables-> Exemples lorsque j'essaie d' ajouter une nouvelle ligne (une ou plusieurs) en cliquant sur le "X". Je ne peux plus supprimer la ligne.

Je ne suis pas un expert en Magento, j'essaie de trouver une solution. Si je trouve que je posterai, si quelqu'un d'entre vous a une solution, ce sera très très utile pour moi

MISE À JOUR : en utilisant Chrome inspecteur, j'ai vu cette erreur:

******* J'AI TROUVÉ LA SOLUTION *******

J'ai passé 2 jours et j'espère que cela pourra aider quelqu'un d'autre, c'est un bug dans SUPEE-8788

Ouvrez samples.phtml à l'intérieur app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable

Trouver la fonction

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

et le remplacer par

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

Cela résoudra le bogue

PATCH_SUPEE-8788_CE_1.9.2.1_v1-2016-10-11-07-00-00-43 a été appliqué à la copie test du site en cours d'exécution 1.9.2.1, qui a cassé la caisse. Retournez le patch et la caisse fonctionne à nouveau normalement.

Lors de la validation de la commande, il vous ramène au panier au lieu d’être validé. Je pense que je vais attendre la version .1 avant de réessayer.

Le nouveau courrier électronique de Magento annoncé aux premières heures de l’écran indique qu’il produira de nouvelles versions de correctifs pour traiter les problèmes de compatibilité SUPEE-1533 et SUPEE-3941. Alors, tenez peut-être un peu vos chevaux.

ENTERPRISE EDITION 1.14.3, COMMUNITY EDITION 1.9.3 ET SUPEE-8788 Enterprise Edition 1.14.3 et Community Edition 1.9.3 apportent plus de 120 améliorations de la qualité, ainsi que la prise en charge de PHP 5.6. Ils résolvent également des problèmes de sécurité critiques, notamment: ...

... Le correctif SUPEE-8788 résout ces problèmes de sécurité dans les versions précédentes de Magento. Malheureusement, nous avons découvert que les correctifs SUPEE-8788 pour Community Edition 1.8 et les versions antérieures et Enterprise Edition 1.13 et les versions antérieures échouaient si un magasin avait précédemment appliqué les correctifs de sécurité SUPEE-1533 ou SUPEE-3941. Nous travaillons à corriger ce problème et fournirons de nouveaux correctifs au cours des trois prochains jours. Jusque-là, nous supprimons ces versions du correctif SUPEE-8788 de la distribution ...

Cependant, je suis préoccupé par le fait que mes versions actives de Magento se situent entre la version CE 1.9.3 qu’ils disent fonctionne et les nouvelles versions à venir pour la version 1.8 et les versions ultérieures. Je les ai contactés alors je vais attendre de voir ce qu'ils disent.

Je ne suis pas un grand fan de patch. Personnellement, je supprime tous les fichiers Magento de leurs répertoires, puis je télécharge la nouvelle version (à l'aide d'un script shell). Tous les fichiers installés au fil des ans, comme des modules ou des thèmes, sont toujours là. Pour la base de données, je compare les nouvelles versions installées. Un moyen consiste à créer ou à supprimer les colonnes / tables de la base de données, l'autre méthode consiste à réinstaller Magento en modifiant simplement le nom du fichier /app/etc/local.xml. Je préfère le premier.

Si vous ne modifiez pas la structure de la base de données vers la version 1.9.3.0, vous obtiendrez des erreurs ou vous ne pourrez pas charger la zone d'administration. Si vous êtes intéressé par certaines comparaisons des répertoires et des bases de données Magento entre Magento CE 1.9.2.4 et 1.9.3.0, téléchargez le fichier à partir d'ici:

Comparaison Magento: versions 1.9.2.4 - 1.9.3.0

Il existe deux fichiers HTML avec de très bons résultats visuels.

J'ai mis à jour 4 magasins aujourd'hui en utilisant ma méthode au lieu de patcher. Tous fonctionnent sans aucun problème.

Ne pas avoir de chance sur la plupart des installations de Magento CE (6 au total). Différentes versions: 1.9.1, 1.9.0.1, 1.8.1.

J'ai téléchargé le correct correct correct 8788 correspondant. Je me suis assuré de retourner 1533 le cas échéant.

J'obtiens les résultats notables suivants qui sont discutables:

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

...

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

... vérification du fichier app / code / core / Mage / Adminhtml / controllers / IndexController.php Le morceau # 1 a réussi à 373 (décalage -19 lignes). ...

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

Comme ci-dessus pour: lib / Unserialize / Reader / Arr.php. Lib / Unserialize / Reader / ArrValue.php. Et dit que ces mecs étaient ignorés.

remarque: il n'y a rien dans mon répertoire Unserialized / Reader. Completement vide. remarque: le fichier Curl.php est dans le répertoire téléchargeur. Non renommé. Il se termine, mais je ne vois pas les fichiers SWF supprimés. Je ne vois pas le correctif appliqué dans la liste de apply.patches.list

Ça n'a aucun sens.

J'ai mis à jour une dizaine de sites Web aujourd'hui, et tous les sites où le correctif SUPEE-8788 a échoué avaient le SUPEE-6788 MISSING .

Cela a abouti à (exemple) l'erreur suivante:

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

Après avoir installé le SUPEE-6788, le SUPEE-8788 a été corrigé correctement.

Si vous obtenez Hunk #1 failedà l'erreur xxx, c'est ce que j'ai fait

Je suis arrivé Hunk #1 failed at 373. Erreur !! après la ligne

vérifiant le téléchargeur de fichier / lib / Mage / HTTP / Client / Curl.php

J'ai donc vérifié le Curl.phpfichier et constaté que j'avais déjà modifié le fichier (commenté sur une ligne). J'ai restauré le fichier d'origine et exécuté le correctif à nouveau. Ensuite, le patch a réussi. ;).

Puis j'ai vérifié:

/app/etc/applied.patches.list & tout semble bien