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


108

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?


6
"il n'y a pas de modèles frontaux impliqués" - n'est pas correct pour les anciennes versions de Magento. Par exemple, le correctif 1.7.0.2 modifie 9 fichiers de modèle frontend / base / default.
Kristof à Fooman

magento.stackexchange.com/questions/140571/… dupes celui-ci? Peut-être regrouper toutes les informations ici ...
7ochem

2
Pour tous ceux qui rencontrent des problèmes avec les mises à jour .swf du correctif, j'ai simplement supprimé les lignes 5951-9818 du correctif et supprimé manuellement les fichiers .swf /skin/adminhtml/default/default/media- car c'est tout ce que le correctif faisait de toute façon.
Liam McArthur

je ne sais pas pourquoi mais après l’installation de 8788 sur la 1.8.0.0, le patch 7405 indique NON installé. alors que v1 et v1.1 étaient précédemment installés
MagenX

2
@srinivas avez-vous supprimé le dossier multimédia de ce chemin skin / adminhtml / default / default?
Priya Ponnusamy

Réponses:


107

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

Problèmes connus de SUPEE-8788 v1

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


1
Merci pour la liste complète! Une question: êtes-vous sûr que le problème de la recherche en texte intégral s'applique au correctif SUPEE-8788? Je ne trouve aucune modification liée à cette fonctionnalité.
Aad Mathijssen

1
@MageDev s'il vous plaît se référer au troisième commentaire de la question;)
Raphael au pianisme numérique

1
Si le Uploader produit ne fonctionne pas après avoir appliqué avec succès le patch et que vous utilisez le plugin CreareSEO populaire alors ce correctif doit être appliqué aussi github.com/adampmoss/CreareSEO/pull/78
joesk

1
J'ai remarqué que vous avez mentionné "La méthode de paiement Paypal Express garantit désormais que le courrier électronique du client utilisé existe dans Magento". Cela signifie-t-il que l'invité ne peut pas vérifier avec PayPal Express? Vous devez être un utilisateur enregistré? Est-ce que je manque quelque chose?
Icône

1
Certaines extensions tierces qui utilisaient l'ancien téléchargeur sont simplement cassées après l'application du correctif. Par exemple, "Magic 360" ajoute un onglet dans les onglets de détails du produit principal. Après le correctif, vous ne pourrez pas voir / éditer les détails de votre produit. J'ai remarqué ce problème au développeur de l'extension sur Magento connect ( magentocommerce.com/magento-connect/… ).
DarkCowboy

29

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

  1. Exécuter le patch

A travaillé pour moi



10
Avez-vous lu la question des PO? fschmengler a demandé: "Néanmoins: avez-vous rencontré des problèmes de compatibilité ou des bugs APRÈS avoir appliqué le correctif?" J'ai rencontré ce problème lors de l'application du correctif. Je suppose que le sens de ce fil est de documenter les erreurs possibles de SUPEE-8788. Cela inclut - IMHO - des problèmes avec le correctif lui-même.
Infabo

Travaillé un régal, merci! Est-il préférable de le faire pour TOUS les futurs correctifs Magento?
KiwisTasteGood

ou vous venez de dos2unix PATCH_SUPEE-8788_CE_1.9.2.4_v1-2016-10-11-07-03-46.sh
fbtb

Généralement, ce n'était pas nécessaire avant et je suppose que ce ne sera pas nécessaire à l'avenir. Je suppose que les fichiers SWF de téléchargement étaient les seuls fichiers binaires livrés avec Magento 1.x - ils sont maintenant partis. Je ne m'attends donc plus à ce que des problèmes comme celui-ci se reproduisent.
Infabo

3
Lorsque vous utilisez FileZilla pour télécharger le .shfichier de correctif sur votre racine Magento, définissez le type de transfert sur binaryavant de télécharger le fichier de correctif. Référence
ForMat

25

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


Si j'ai bien compris, vous avez annulé le correctif d'origine 1533, installé SUPEE 8788, puis à nouveau installé 1533 ?? Est-ce que je comprends bien?
Icône

J'ai également un problème avec FAILED HUNK à 28 app / design / frontend / base / default / template / review / form.phtml
Icône

9
Je me demande bien pourquoi, lorsque nous prenons le temps d'appliquer correctement les correctifs incrémentiels officiels, nous sommes pénalisés en procédant ainsi à des corrections manuelles lorsque les correctifs ne fonctionnent pas lorsque les correctifs précédemment fournis ont été appliqués. Une approche très étrange.
Jon Holland

1
La plupart des versions inférieures à la version 1.9 sur lesquelles SUPEE 1533 est installé ne peuvent pas installer le patch correctement. SUPEE 8788 n'est pas compatible avec 1533
Icon

2
@ JonHolland Parce que, eh bien, c'est Magento.
Agop

25

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

  1. Commentaire _apply_revert_patchà#_apply_revert_patch

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

  3. grep pour tous les fichiers .rej avec

    git status | grep *.rej

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


La clé de formulaire ajoutée lors de la mise à jour d'un élément de devis dans le panier n'est pas quelque chose qui a été ajouté avec SUPEE-8788 (pas à partir du 1.9.2.4 au minimum)
Raphael chez Digital Pianism

@RaphaelatDigitalPianism, à tout le moins, le correctif 1.13.0.1 ajoute la validation de clé de formulaire à Mage_Checkout_CartController::updatePostAction, potentiellement, d'autres versions de correctif.
Luke Rodgers

23

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

1
Je sais que Fishpig exige que vous le fassiez. Donc, si vous avez installé cela, ce sera un problème pour vous.
mpchadwick

1
Note: J'étais confus et c'est MWI qui vous demande de remplacer functions.php, pas Fishpig mwi-plugin.com/documentation/installation
mpchadwick

18

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 .


Belle prise, Matthias! Ce serait un peu mauvais de déployer 17 correctifs APPSEC et d’ouvrir un autre vecteur en même temps. L'avez-vous déjà signalé à Magento?
Bryan 'BJ' Hoffpauir Jr.

J'ai ouvert un ticket à ce sujet avec l'assistance de Magento, comme d'autres, à présent, en sont certains. N'a pas entendu parler d'une version v2 du correctif, mais ils devraient être au courant du problème.
quasi

1
Il y aura une v2, devrait être publié très bientôt. Oui, je l'ai signalé quand j'ai posté ici.
Matthias Zeis

1
On dirait que c'est corrigé maintenant
Erfan

18

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.


Nous avons été abandonnés
datasn.io

@ kavoir.com, vous obtenez également la même erreur CURL.PHP lors de l’installation sur 1.7.0.2 ??
Icon

1
Même problème ici, installez 8788 V2 sur 1.7.0.2, bien que ce soit intéressant, nous obtenons la même erreur curl.php sur nos sites les plus récents, la version 1.9.2.1, pour lesquels SUPEE-3941 n’est pas disponible. revenir 1533 n'aide pas ce problème non plus
Jon Holland

@JonHolland J'ai écrit à l'équipe de magento ... J'espère qu'ils vont répondre
Icon

2
J'ai reçu une réponse du responsable de la communauté magento. En principe, il est correct d'installer le correctif 3941 sur la version 1.7.0.2.
Icon

15

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?


2
IMO Le résultat final souhaité est un mélange des deux. Ce devrait être json_decode, mais il devrait utiliser hash_equals plutôt que ==. Cela empêche un timing d'attaquer (ce qui serait extrêmement difficile à exploiter).
Peter O'Callaghan

D'accord avec @Peter. Si vous utilisez Git, annulez la validation pour SUPEE-1533, appliquez le nouveau correctif, validez, puis annulez à nouveau la validation annulée. Le conflit en DashboardController.phpdevrait être résolu automatiquement alors.
Fabian Schmengler

1
Pourriez-vous s'il vous plaît fournir un morceau de code pour DashboardController.php que nous devrions remplacer après l'installation de 8788? Je ne sais pas exactement quoi éditer, comme je l'ai mentionné plus haut, les lignes 1533 et 8788 patchd sont différentes. Pourriez-vous s'il vous plaît indiquer comment une version modifiée manuellement devrait ressembler?
Icône

Est-ce à quoi devrait ressembler le code 8788 après une modification manuelle avec la mise à jour 1533? if (hash_equals ($ newHash, $ gaHash)) {if ($ params = json_decode (base64_decode (urldecode ($ gaData)))))
Icône du

1
Remarque concernant l' annulation des validations à deux reprises: vous pourrez peut-être utiliser git revert -n 123456abet git cherry-pick -n 123456abannuler temporairement SUPEE-1533 sans créer de validations supplémentaires.
Matthias Zeis

14

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() ?>" />

Existe-t-il une liste complète des formulaires concernés? Je peux donc tester et corriger TOUS les problèmes une fois pour toutes. Vous ne voulez pas de tels dysfonctionnements secrètement stupides pour ennuyer les clients ou réduire le taux de conversion.
datasn.io

Si un SUPEE 8788 s’installe parfaitement sur la version 1.7 et apporte des modifications dans (app / design / frontend / base / default / template .....). Mais malgré les modifications apportées à la liste de souhaits du site Web, les boutons de suppression s’affichent parfaitement. Avons-nous encore besoin de patcher manuellement les fichiers de thème? Ou bien, tant que patch ne casse rien sur le front-end, on peut laisser tel quel?
Icon

11

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


10

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.


avez-vous déjà trouvé une solution à cela? Je l'ai corrigé en remplaçant $ this-> getUploader () -> getConfig () par $ this-> getUploader () -> getUploaderConfig () dans Unirgy_RapidFlow_Block_Adminhtml_Profile_Edit_Tab_Upload
Lilaconacono

Bon à maintenant. Unirgy semble également l'avoir corrigé dans la version 2.0.0.23. secure.unirgy.com/release-notes.php?m=1#RapidFlow Je travaille avec un client pour acheter des mises à niveau supplémentaires et je n'ai pas été en mesure de le valider.
mpchadwick

lancez ceci sur votre docroot pour trouver quels autres fichiers doivent être corrigés: grep -r 'getUploader () -> getConfig ()' ./
lloiacono

8

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.


8

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

J'ai personnalisé les fichiers de correctifs pour qu'ils fonctionnent pour toutes les versions de Magento après avoir installé tous les correctifs précédents: magentohosting.pro/files/MageHost.pro_fixed_SUPEE-8788_v2.zip
Jeroen Vermeulen - MageHost Le

8

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

Obtenir exactement la même erreur lors d’une installation. J'adorerais savoir si vous avez compris quelque chose.
TunaMaxx

Non, j'attends toujours que quelqu'un d'autre s'en rende compte
Haïm

2
Voir magento.stackexchange.com/a/73957/9276 . Si votre fichier Curl.php contient ce correctif, annulez cette modification (rétablissez la ligne sur CURLOPT_SSL_CIPHER_LIST / 'TLSv1'), appliquez le correctif, puis rétablissez la modification.
Joe

Merci @ Joe. Je venais juste de revenir ici pour poster les mêmes informations. Vous m'avez battu à ça! C'est ce que je reçois pour aller dormir. :)
TunaMaxx

Avait le même problème, cela l'a résolu. Merci!
dafyddPrys

8

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


1
Si le correctif mis à jour produit exactement le même résultat que nos correctifs manuels, et j'espère que c'est le cas, alors je ne vois pas de problème. Le correctif mis à jour ne sera pas nécessaire et les futurs correctifs ne verront aucune différence.
Fabian Schmengler

1
@fschmengler est assez similaire à l'incompatibilité PHP 5.5 pour SUPEE-7405 IMO. Le correctif reflétera le correctif manuel.
Raphael au Digital Pianism

1
@fschmengler À ma connaissance, magento publiera à nouveau exactement le même correctif avec des correctifs. Je lui donne le meilleur pour supprimer l'ancien correctif (auto-modifié) et installer un nouveau (probablement publié le lendemain. D'ici demain, nous devrions avoir la mise à jour. Merci pour l'aide!
Icon

Je ne doute pas de la valeur de cette contribution, mais, s’en tenir au style des questions-réponses, cette réponse ne me semble pas être une réponse, mais plutôt une mise à jour que @fschmengler pourrait ajouter à sa question initiale (ou vous pouvez l’ajouter au Réponse du wiki de la communauté).
7ochem

8

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.


Solution possible pour l'erreur type de données non pris en charge N gist.github.com/balloz/ceaf5feb5ac66caaa82342441d32aa88
Raphael chez Digital Pianism

Toute idée de comment surmonter l'erreur Curl.php lors de l'installation de SUPEE 8788 sur les versions 1.6 et 1.7?
Icône

8

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.


Il s’avère que c’est le comportement de la librairie
Laura

6

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


2
Ayant maintenant appliqué la V2 du correctif, je rencontre le même problème avec le correctif EE1.12. Il semble que ce fichier ait changé à un moment donné entre 1.12 et 1.14 mais pas dans le cadre des correctifs
Chris

1
A soulevé cette question avec Magento et ils ont fourni un correctif supplémentaire pour résoudre le problème. Le changement est identique à celui ci-dessus.
Chris

6

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')?


4
Attention, <?=il n'est pas activé sur toutes les configurations php
Raphael au Digital Pianism

@ RaphaelatDigitalPianism vous avez raison. Bien qu'il <?=soit activé par défaut dans la plupart des configurations php.ini, certains hôtes choisissent de le désactiver.
Sergei Filippov

5

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

5

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>

4

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.


Si je comprends bien, le 8788 annule les modifications apportées dans DashboardController.php, et les modifications initiales de 1533 seront éliminées?
Icône

2
Oui, le but de 1533 de remplacer serialize () par json_encode () était de réduire les chances d’attaque ($ newHash == $ gaHash). Tandis que 8788 ajoute hash_equals () dans le même but
William Zhao

Génial, je pensais en faire un peu autrement, sur mon site de test, j’ai téléchargé propre DashboardController.php (fichier de stock magento) et installé SUPEE 8788. Cependant, j’ai lu sur ce forum et un monsieur mentionné pour réintroduire manuellement les modifications apportées à Supee 1533 dans Supee 8988 fichier modifié. Que pensez-vous de ma méthode?
Icon

Icône, regardez mon diff ci-dessus, à votre manière, vous devez revenir dans la ligne mise à jour par SUPEE 1533 dans 'app / code / core / Mage / Adminhtml / Block / Dashboard / Graph.php' également si vous avez déjà SUPEE 1533 patché. Sinon Graph.php lancera des paramètres au format JSON et vous ne pourrez pas le décoder par unserialize ()
William Zhao

4

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


4

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.entrez la description de l'image ici

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:entrez la description de l'image ici

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


3

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.


sonne comme si une exception est levée pendant que la commande est sauvegardée, avez-vous vérifié vos journaux?
simonthesorcer

Cela ressemble à ... PHP Erreur fatale: la classe 'Mage_Core_Helper_UnserializeArray' est introuvable ... / public_html / app / Mage.php à la ligne 547
Adam Lavery

@AdamLavery Accédez à Var / cache et supprimez le dossier de cache. Je reçois cette erreur lorsque je reviens aux paches. C'est une chose de cache.
Icon

Un nouveau patch devrait sortir bientôt. C'est une mise à jour énorme pour ne pas s'attendre à des erreurs ... Ouais ... doigts croisés.
Icône

1
Ceci est probablement dû à votre absence. app/code/core/Mage/Core/Helper/UnserializeArray.phpCeci a été ajouté à SUPEE-6788, que vous n'avez peut-être pas installé. Il semble que SUPEE-8788 ait une dépendance non documentée sur SUPEE-6788.
Tyler V.

3

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.


Pas vraiment une "réponse" mais des informations utiles, espérons-le.
Jon Holland

Bonjour Jon, vous pouvez également éditer la question initiale de @ fschmengler et l'ajouter en bas sous la forme d'une MISE À JOUR . Je pense qu'il serait d'accord avec cela et approuver ce montage.
7ochem

Bonne idée mais quelqu'un a déjà ajouté quelque chose :)
Jon Holland

3

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.


C'est bien si vous utilisez la version la plus récente et qu'il y a une nouvelle version du correctif, comme ce fut le cas avec 1.9.2.2, 1.9.2.3 et 1.9.2.4 - cependant, pour ce correctif, il n'y avait pas de nouvelle version 1.9.2.5. . La version 1.9.3.0 contient un ensemble de modifications supplémentaires qui ne sont pas liées à la sécurité.
Fabian Schmengler

Avec ma méthode, j'ai deux en un, les mises à jour de sécurité et les nouvelles fonctionnalités. Le seul problème est que vous devez comprendre ce qui se passe dans le système de fichiers et la base de données entre les versions. Ce n'est pas grave quand vous savez ce que vous faites. Et vous avez un meilleur contrôle. Je fais cette méthode depuis la version 1.7.
ADDISON74

3

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.


Ok .. j'ai tout compris. Il faut absolument travailler dans TOUS les anciens correctifs, dans l’ordre. J'ai eu quelques patchs plus anciens qui n'avaient pas été appliqués. Une fois que j'ai tiré ceux-ci et appliqué sur la ligne, les choses ont commencé à patcher avec succès. Cependant, j’ai constaté que chaque fois que j’obtenais une erreur significative sur un fichier correspondant à TOUT correctif, je devais entrer dans le correctif et trouver ce qu’il essayait de remplacer et le faire manuellement dans mon installation de magento. ALORS, supprimez ces lignes "diff" du patch et relancez-les. Essentiellement, chaque fois que vous voyez une erreur de morceau, allez dans le correctif et voyez ce qu'il tente de +/-, puis faites-le vous-même.
Rich Yessian

3

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.


3

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

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