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

45

Magento a publié un nouveau correctif de sécurité pour M1 et des mises à jour pour M1 et M2.

Quels problèmes dois-je rechercher lors de la mise à niveau ou de l'application de ce correctif?

SUPEE-10570

SUPEE-10570, Magento Commerce 1.14.3.8 et Open Source 1.9.3.8 contiennent plusieurs améliorations de sécurité permettant de fermer l’exécution de code à distance (RCE), le script intersite (XSS) et d’autres problèmes. Ces versions incluent également de petits correctifs fonctionnels répertoriés dans la notes de version.

MAGENTO 2.2.3, 2.1.12 ET 2.0.18 MISE À JOUR DE SÉCURITÉ

Magento Commerce et Open Source 2.2.3, 2.1.12 et 2.0.18 contiennent de nombreuses améliorations de sécurité permettant de fermer les scripts XSS (Cross-Site Scripting), l’exécution de code à distance par les utilisateurs authentifiés (Admin) et d’autres vulnérabilités. Les versions incluent des correctifs fonctionnels supplémentaires. Pour en savoir plus sur les correctifs fonctionnels, veuillez consulter les Notes de publication pour Magento Commerce 2.0.18, 2.1.12, 2.2.3 et Magento Open Source 2.0.18, 2.1.12, 2.2.3.

Ryan Hoerr
la source
1
Pour Open Source / Community Edition 1.x, aucun changement de modèle d’ interface frontale ne semble être inclus. Par conséquent, cela ne devrait pas au moins créer trop de problèmes. Cependant, une sauvegarde de la base de données est vivement recommandée car ce script contient deux scripts d'installation (mise à niveau). Plus de détails peuvent suivre après avoir patché les premiers environnements.
Christoph Farnleitner
1
Si vous avez des magasins qui utilisent une grille adminhtml personnalisée qui inclut le nom du magasin, le correctif l’échappe maintenant probablement pour corriger certains exploits potentiels basés sur la modification du nom et du rendu du magasin.
Andrew Quackenbos
J'ai jusqu'ici patché 2 sites sur 1.9.0.1 sans problème.
asdfasdfasf
1
J'ai appliqué le correctif sur 1.9.3.0, 1.9.0.1 et 1.9.1.0 jusqu'à présent, aucun problème
David
2
Ceci provient du blog sur la sécurité: magento.com/security/patches/supee-10570 REMARQUE: certains clients rencontrent des problèmes lors du paiement lorsqu'ils tentent de créer un compte lors de leur commande. Un correctif de mise à jour ou une solution de contournement pour résoudre ce problème sera disponible sous peu. Si vous rencontrez actuellement ce problème, envisagez d'inverser la partie du code à l'origine de ce problème en appliquant le correctif suivant: invalid_sesssion_fix.patch à partir des archives de publication, section SUPEE-10570
The Tankgirl

Réponses:

29

Voici la liste des fichiers modifiés par le correctif SUPEE-10570:

app/Mage.php 
app/code/core/Mage/Admin/Helper/Data.php
app/code/core/Mage/Admin/Model/Block.php 
app/code/core/Mage/Admin/Model/Resource/Block.php 
app/code/core/Mage/Admin/Model/User.php 
app/code/core/Mage/Adminhtml/Block/Catalog/Category/Edit/Form.php 
app/code/core/Mage/Adminhtml/Block/Catalog/Product/Grid.php 
app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Grid/Renderer/Sender.php 
app/code/core/Mage/Adminhtml/Block/Sales/Order/Grid.php 
app/code/core/Mage/Adminhtml/Block/Sales/Order/View/Info.php 
app/code/core/Mage/Adminhtml/Block/System/Store/Edit/Form.php 
app/code/core/Mage/Adminhtml/Block/Tag/Assigned/Grid.php 
app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Renderer/Store.php 
app/code/core/Mage/Adminhtml/Block/Widget/Tabs.php 
app/code/core/Mage/Adminhtml/Model/Config/Data.php 
app/code/core/Mage/Adminhtml/Model/System/Store.php 
app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php 
app/code/core/Mage/Adminhtml/controllers/CustomerController.php 
app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
app/code/core/Mage/Core/Model/Variable.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/etc/config.xml
app/code/core/Mage/Customer/sql/customer_setup/upgrade-1.6.2.0.1.1.1-1.6.2.0.1.1.2.php
app/code/core/Mage/Downloadable/etc/config.xml
app/code/core/Mage/Downloadable/etc/system.xml
app/code/core/Mage/Downloadable/sql/downloadable_setup/upgrade-1.6.0.0.2.1.1-1.6.0.0.2.1.2.php
app/code/core/Mage/ImportExport/Model/Import.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Product.php
app/code/core/Mage/Shipping/Model/Info.php
app/code/core/Mage/Widget/controllers/Adminhtml/Widget/InstanceController.php
app/design/adminhtml/default/default/template/catalog/product/attribute/set/main.phtml
app/design/adminhtml/default/default/template/customer/tab/view.phtml
app/design/adminhtml/default/default/template/customer/tab/view/sales.phtml
app/design/adminhtml/default/default/template/dashboard/store/switcher.phtml
app/design/adminhtml/default/default/template/downloadable/product/composite/fieldset/downloadable.phtml
app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable/links.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/creditmemo/name.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/invoice/name.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/name.phtml
app/design/adminhtml/default/default/template/newsletter/preview/store.phtml
app/design/adminhtml/default/default/template/report/store/switcher.phtml
app/design/adminhtml/default/default/template/sales/order/view/info.phtml
app/design/adminhtml/default/default/template/store/switcher.phtml
app/design/adminhtml/default/default/template/store/switcher/enhanced.phtml
app/design/adminhtml/default/default/template/system/convert/profile/wizard.phtml
app/design/adminhtml/default/default/template/tax/rate/title.phtml
app/design/adminhtml/default/default/template/widget/form/renderer/fieldset.phtml
app/locale/en_US/Mage_Catalog.csv
app/locale/en_US/Mage_ImportExport.csv
lib/Zend/Mail/Transport/Sendmail.php

MODIFIER

Enfin, après le déploiement sur mon site Web prod (CE 1.7.0.2), j’ai remarqué un problème critique de blocage (processus de commande bloqué).

Le contexte: après l’étape 1 de l’adresse, je crée directement ET connecte le client, il ne devrait voir que la prochaine étape de paiement.

Le problème: après supee-10570, le processus de commande est interrompu après l'étape 1 (en cas de création de compte) et le client est redirigé vers la page d'accueil (avec un panier vide + déconnecté) = impossible de réaliser sa commande.

Le correctif d’urgence: si vous rencontrez un problème similaire avec votre commande / session client, commentez les lignes 414 à 430 de app / code / core / Mage / Core / Modèle / Session / Abstract / Varien.php (celles ajoutées par le patch , voir ci-dessous).

//         if ($this->useValidateSessionPasswordTimestamp()
//             && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
//             > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
//         ) {
//             return false;
//         }

//         if ($this->useValidateSessionExpire()
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
//             return false;
//         } else {
//             $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
//                 = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
//         }

EDIT (2)

Je pense que la condition suivante retournera toujours false (Mage_Core_Model_Session_Abstract_Varien aux lignes 414 à 419, en particulier les lignes 417 + 418).

if ($this->useValidateSessionPasswordTimestamp()
            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
        ) {
        return false;

VALIDATOR_PASSWORD_CREATE_TIMESTAMP sera toujours supérieur à VALIDATOR_SESSION_EXPIRE_TIMESTAMP. L'horodatage de session "expiration" est redéfini lors de la création du compte, donc inévitablement plus ancien que la session init.

Ainsi, par exemple, si vous créez le client lors du paiement, le résultat sera false et le client sera simplement expulsé (= terminer le paiement, rediriger vers la page d'accueil et le panier vide). Plutot mauvais.

J'ai signalé ce problème à l'équipe de magento. Je vais donner des commentaires ici dès que possible.


EDIT (3)

Un nouveau correctif est wip (sur la page de téléchargement du correctif magento, il est écrit "SUPEE-10570 pour CE 1.7.0.0 - MISE À JOUR DU PATCH ATTENDUE, NE PAS UTILISER (0,06 Mo)").


EDIT (4) ~ 1 mois après le signalement du problème de blocage initial

Salut! J'espère que vous êtes tous des biens (et espérons que vous n'avez pas conservé l'état initial du patch jusqu'à présent, à moins que vos revenus commerciaux n'aient probablement sérieusement diminué ^^).

J'ai remarqué la phrase suivante de la page officielle: "Magento fournit maintenant un correctif mis à jour (SUPEE-10570v2) qui ne provoque plus ce problème. Notez cependant que ce nouveau correctif ne protège plus contre deux problèmes liés au traitement de la session problèmes de sécurité contre lesquels le correctif SUPEE-10570 est protégé. " de la page officielle supee-10570.

Sur la page de publication, nous pouvons enfin trouver le fichier v2 (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).

J'ai étudié les modifications dans les détails. Enfin, il semble que l’équipe de magento a décidé de supprimer une partie du correctif liée à la sécurité. Espérons que cette faille de sécurité ne causera pas de dommages graves (sa note critique est basse).

Après avoir restauré la v1 + appliquer la v2, veillez à ce que les fichiers suivants soient rétablis dans leur état initial (avant l'application de la v1):

app/code/core/Mage/Adminhtml/controllers/CustomerController.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php

PS: évidemment, d’autres fichiers sont également modifiés, veuillez vérifier en conséquence.

DarkCowboy
la source
1
@Icon: je viens de signaler ce bug à magento. Je publierai la réponse dès que je recevrai un feedback officiel.
DarkCowboy
4
@Icon / Soleil: Malheureusement, toujours pas de réponse officielle ou de correction concernant ma demande de correction de bug.
DarkCowboy
1
@DarkCowboy Je viens de remarquer qu'une fois que vous avez accédé à la page de téléchargement du correctif, vous pouvez voir que l'équipe Magento a ajouté une note dans les correctifs 1.7.0.0 et 1.7.0.2. On dirait que le nouveau patch arrive.
Icône
3
Salut à tous. J'ai vu qu'un nouveau correctif a été ajouté ("PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-28-04-54-53.sh"). Vous pouvez voir la différence ici (le volet de gauche est le premier correctif "PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-23-06-28-18.sh"): diffchecker.com/uGON91aR . Donc pas de solution pour le nouveau patch?! De plus, l'avis "... MISE À JOUR PATCH ATTENDUE, NE PAS UTILISER" a disparu. Je suis donc un peu déroutant par ce que l'équipe principale de magento fait avec ce problème.
DarkCowboy
1
FYI, la version 2 du correctif contient toujours "SUPEE-10570_CE_v1.9.2.4 | CE_1.9.2.4 | v1" inapp/etc/applied.patches.list
Moose
9

(je ne sais pas si c'était dans les notes de publication depuis le début)

Problèmes connus

Ces deux problèmes connus sont associés à l'utilisation de balises HTML dans l'attribut SKU d'un produit:

  • Si vous essayez d'importer des produits contenant des balises HTML dans l'attribut SKU, Magento affiche cette erreur à l'étape de validation des données (c'est-à-dire lorsque vous cliquez sur Vérifier les données ):
 Invalid value in SKU column. HTML tags are not allowed.
  • Si vous essayez de créer ou de modifier un produit dans le panneau d'administration et que la valeur de l'attribut SKU du produit contient des balises HTML, Magento lève cette erreur lorsque vous essayez d'enregistrer le produit: HTML tags are not allowed in SKU attribute.

De notes de patch :

Si le correctif ne parvient pas à s’appliquer lorsqu’il corrige lib/Zend/Mail/Transport/Sendmail.php, cela pourrait signifier que votre installation de Magento avait déjà été corrigée avec SUPEE-9652v1 au lieu de SUPEE-9652v2. La solution recommandée consiste à remplacer le correctif SUPEE-9652v1 et à appliquer SUPEE-9652v2 avant d’appliquer SUPEE-10570.

sv3n
la source
7

J'ai eu le même problème que @DarkCowboy après avoir appliqué le correctif à Magento CE 1.7.0.2.

Après avoir choisi de vous enregistrer en tant que nouveau client lors de la validation de votre commande, la commande crée à la fois la commande et le client, mais au lieu d’afficher la page de succès de la commande, je suis redirigé vers la page d’accueil et déconnecté.

La solution que j'ai trouvée consiste à inverser l'ordre des blocs de code dans les modifications app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.

En comparant la version corrigée avec le même fichier dans Magento CE 1.9.3.8, j’ai trouvé que les nouveaux blocs permettant de valider l’expiration de la session et l’horodatage du mot de passe sont dans un ordre différent.

Magento CE 1.9.3.8 - Lignes 476-491:

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

Magento CE 1.7.0.2 - Lignes 414-430:

    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }

Cela donne la valeur $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]supérieure à $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime(), ce qui signifie que la méthode retourne toujours la valeur false et que la validation échoue.

Changer le code dans Magento CE 1.7.0.2 pour qu'il corresponde à la version de Magento CE 1.9.3.8 corrige le problème.

Le code résultant pour Magento CE 1.7.0.2 - Lignes 414-430:


    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

Je suggérerais de créer votre propre fichier de correctif et de l'appliquer directement au fichier principal (c'est ainsi que j'aborde normalement la correction des bogues dans le noyau). Cela faciliterait la restauration si Magento publiait une version 2 du correctif.

Dave Herbert
la source
Salut Dave. Il semble que vous ayez rencontré le même problème que moi. En ce qui concerne votre solution, avec votre inversion, la seconde condition ne sera pas testée du tout ... J'examinerai ces données de session.
DarkCowboy
4
Mise à jour du 1.7.0.2 prévue mi-mars. (v2 du correctif), le problème est confirmé.
Piotr Kaminski
Quelqu'un a-t-il testé si cette solution permettait au contrôle de l'horodatage de changer le mot de passe de fonctionner ou si elle rouvrait la faille de sécurité qu'ils essayaient de corriger? Remarque: Si vous ne se soucient pas de la prestation de la sécurité, vous pouvez tout simplement désactiver l' horodatage de changement de mot de passe de vérification alltogether en ayant useValidateSessionPasswordTimestamp()retour false. (un changement de ligne dans le même fichier)
Eric Seastrand
Salut. Nous avons évalué que le problème de "redirection avec panier vide" existait toujours avec l'ordre de validation modifié. Nous avons désactivé la vérification "useValidateSessionPasswordTimestamp" jusqu'à ce que magento crée une mise à jour.
Steven Fritzsche
6

Nous avons vu une page vierge à / checkout / cart après l’application de SUPEE-10570 et la compilation. Juste pour clarifier les choses: avec le compilateur désactivé, tout se passait bien, avec le compilateur activé, nous ne pouvions voir qu'une page de panier vide lorsque vous vous connectiez sans entrées de journal (même après avoir activé tous les journaux possibles et le mode développeur).

La solution consistait à modifier la fonction getPasswordTimestamp()en app/code/core/Mage/Customer/Helper/Data.php(bien sûr signifie app/code/local/Mage/Customer/Helper/Data.php:!) Et à utiliser à la Mage::getSingleton('core/resource')place de Mage::getModel('customer/customer')ou Mage::getSingleton('customer/session'). Donc, remplacez toute la fonction, par exemple avec ces lignes de code:

    $resource = Mage::getSingleton('core/resource');
    $readConnection = $resource->getConnection('core_read');
    $query = 'SELECT * FROM ' . $resource->getTableName('customer_entity').' WHERE `entity_id` = '.$customerId;
    $results = $readConnection->fetchAll($query);
    $result=$results[0];
    $date_created = Varien_Date::toTimestamp($result['created_at']);
    return $date_created;

Après la recompilation, le problème avait disparu. Quelqu'un d'autre avec ce problème?

Explication en allemand ici .

Bastian Kretzschmar
la source
C’est à bien des égards différents des pires conseils et codes jamais vus ici. S'il vous plaît ne faites rien de cela à la maison.
Pong
C'est exactement pareil avec moi. Ce patch ne fonctionne pas avec le compilateur activé.
Rafael Patro
Dans 1.9.3.9 cela fonctionne très bien pour moi.
TonkBerlin
4

1.7.0.0

Pièce: PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh

Cette erreur se produit si vous n'avez pas déjà appliqué SUPEE-9652 ou SUPEE-9767

patching file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 130.

Appliquez ces correctifs pour corriger le problème.

Tyler V.
la source
2
Assurez-vous que 9652 et 9767 sont installés
Icon
En effet, nous avons testé SUPEE-10570 sur toutes les versions vanilla de Magento depuis la version 1.6.0.0 et tout fonctionne. Mais seulement si vous avez appliqué tous les correctifs précédents. Vous pouvez y rechercher les correctifs requis: docs.google.com/spreadsheets/d/…
Jeroen Vermeulen - MageHost
4

1.7.0.0

PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh Fichier de correctionapp/code/core/Mage/Core/Model/Session/Abstract/Varien.php

Le correctif pour 1.7.0.0 ajoute seulement une constante:

+    const VALIDATOR_PASSWORD_CREATE_TIMESTAMP   = 'password_create_timestamp';

Cependant, il ajoute l'utilisation de deux nouvelles constantes, notamment celle-ci:

+        if ($this->useValidateSessionPasswordTimestamp()
+            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
+            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
+            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
+            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
+        ) {
+            return false;
+        }

Cela entraîne l'erreur:

PHP Fatal error:  Uncaught Error: Undefined class constant 'VALIDATOR_SESSION_EXPIRE_TIMESTAMP' in 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php:406
Stack trace:
#0 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(358): Mage_Core_Model_Session_Abstract_Varien->_validate()
#1 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(176): Mage_Core_Model_Session_Abstract_Varien->validate()
#2 
app/code/core/Mage/Core/Model/Session/Abstract.php(84): Mage_Core_Model_Session_Abstract_Varien->init('core', 'frontend')
#3 
app/code/core/Mage/Core/Model/Session.php(42): Mage_Core_Model_Session_Abstract->init('core', 'frontend')
#4 
app/code/core/Mage/Core/Model/Config.php(1354): Mage_Core_Model_Session->__construct(Array)

Le correctif:

Ajoutez une définition pour cette seconde constante au-dessus ou au-dessous de la première constante ajoutée par ce patch.

const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';

Jusqu'ici, je n'ai vu ce problème dans aucun des 1.9. ou les correctifs 1.14.x, car ils définissent la constante correctement.

Tyler V.
la source
Ceci a été corrigé en ajoutant const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';en haut du fichier, comme dans la plupart des autres versions de ce correctif.
Tyler V.
Yep semble être spécifique à 1.7.0.0 patch
danmentzer
Tyler pouvez-vous ajouter le correctif à votre réponse plutôt qu’à la section commentaires.
danmentzer
1
Aussi, je voudrais juste noter que cela affecte également les correctifs pour la version EE du correctif ainsi que EE 1.12.0.0
danmentzer
3

Tout d’abord, vérifiez si la version correcte de SUPEE-6788 ou SUPEE-7405 a déjà été appliquée, sinon retournez la mauvaise version et appliquez la version correcte de SUPEE-6788 / SUPEE-7405.

Puis réessayez d'appliquer SUPEE-10570.

Vio
la source
2

Les fichiers ci-dessous sont mis à jour / ajoutés après l’application du correctif SUPEE - 10570 dans EE.

@DarkCowboy a fourni une liste de fichiers autres que les fichiers EE :

    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Hierarchy/Edit/Form.php
    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Hierarchy/Widget/Chooser.php
    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Page/Edit/Tab/Hierarchy.php
    app/code/core/Enterprise/Cms/Block/Hierarchy/Menu.php
    app/code/core/Enterprise/Customer/Block/Adminhtml/Customer/Attribute/Edit/Tab/Main.php
    app/code/core/Enterprise/GiftRegistry/Model/Observer.php
    app/code/core/Enterprise/Reward/Block/Adminhtml/Customer/Edit/Tab/Reward/Management/Update.php
    app/code/core/Enterprise/Rma/Model/Shipping/Info.php
    app/code/core/Enterprise/Staging/Block/Adminhtml/Backup/Grid.php
    app/code/core/Enterprise/Staging/Block/Adminhtml/Staging/Grid.php
 app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/edit.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/scope/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/widget/radio.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/page/preview/store.phtml
    app/design/adminhtml/default/default/template/enterprise/customer/website/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/invitation/view/tab/general.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/log/information/create.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/edit/tabs/website.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/edit/tabs/website/store.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/merge/settings/website.phtml
    app/design/adminhtml/default/default/template/enterprise/store/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/store/switcher/enhanced.phtml
    app/design/adminhtml/default/default/template/merchandiser/new/page/html/top-buttons.phtml
    app/design/frontend/enterprise/default/template/cms/hierarchy/pagination.phtml

Quelques notes importantes

password_created_at créé dans la table des attributs du client.

app/code/core/Mage/Adminhtml/controllers/CustomerController.php
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/sql/customer_setup/upgrade-1.6.2.0.5.1.1-1.6.2.0.5.1.2.php

Ces fichiers sont utilisés pour la création et la validation. un problème de session se produit lors de la validation de la commande ou de la connexion de l'utilisateur, l'un des fichiers ci-dessus est écrasé dans votre pool local ou un password_created_atattribut est créé dans votre table d'attributs client et la valeur appropriée est stockée dans cette table.

Rama Chandran M
la source
Je n'ai pas trouvé mot de passe_created_at dans la base de données CE où le problème est également signalé.
TonkBerlin le
vérifier ce fichier app / code / core / Mage / Client / sql / customer_setup / upgrade-1.6.2.0.5.1.1-1.6.2.0.5.1.2.php
Rama Chandran M
2

Ma version de magento est ver. 1.9.1.0.

Nous avons vu une page vierge à / checkout / cart après l’application de SUPEE-10570 et la compilation. Juste pour clarifier les choses: avec le compilateur désactivé, tout se passait bien, avec le compilateur activé, nous ne pouvions voir qu'une page de panier vide lorsque vous vous connectiez sans entrées de journal (même après avoir activé tous les journaux possibles et le mode développeur).

Cause:

  1. la fonction getPasswordTimestamp invoquera deux fois une fois connecté et visité / checkout / cart.

  2. compilateur désactivé à la fois appel travail.

  3. n'activez le compilateur que pour le premier travail d'appel, le second appel a échoué.

quelqu'un peut-il expliquer et donner la bonne solution?

jun
la source
2

Un problème avec 1.7.0.2 que j'ai remarqué est le suivant:

  1. Ajouter le produit au panier et aller à la caisse

  2. Cliquez sur "S'inscrire"

  3. Remplissez toutes les informations de commande nécessaires, y compris les détails de paiement, etc.
  4. Cliquez sur Terminer la commande.

LE PROBLEME COMMENCE ICI

5. Être automatiquement redirigé vers la PAGE D'ACCUEIL. Vous ne voyez pas la confirmation du numéro de commande. Mais en réalité, la commande est passée et le compte client créé.

Icône
la source
Avez-vous trouvé une solution pour cela? Je suis confronté au même problème.
Parth Thummar
1
Le patch V2 est sorti, le problème est résolu
Icon
2

J'ai rencontré le même problème, Magento 1.9.3.8 a ajouté cette méthode à la classe Mage_Customer_Helper_Data

/**
 * Get customer password creation timestamp or customer account creation timestamp
 *
 * @param $customerId
 * @return int
 */
public function getPasswordTimestamp($customerId)
{
    /** @var $customer Mage_Customer_Model_Customer */
    $customer = Mage::getModel('customer/customer')
        ->setWebsiteId(Mage::app()->getStore()->getWebsiteId())
        ->load((int)$customerId);
    $passwordCreatedAt = $customer->getPasswordCreatedAt();

    return is_null($passwordCreatedAt) ? $customer->getCreatedAtTimestamp() : $passwordCreatedAt;
}

Si vous surchargez cette classe dans le dossier Local (ce n’est pas la meilleure pratique), des erreurs peuvent être générées par cette classe.

Phanvugiap
la source
2

Ce correctif a endommagé une partie du gestionnaire de hiérarchie du CMS pour les utilisateurs EE.

Ceci est dû à la ligne de correction suivante qui est chargée d'échapper aux noms de magasins / sites Web et de corriger APPSEC-1873/1979/1980.

diff --git app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
index e45298c..8bee617 100644
--- app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
+++ app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
@@ -36,7 +36,7 @@
             <div class="cms-popup-description"></div>
             <div class="fieldset">
                 <div class="cms-hierarchy manage-form">
-                    <?php echo $this->getFormHtml() ?>
+                    <?php echo $this->escapeHtml($this->getFormHtml()); ?>
                 </div>
             </div>
         </div>

Le sélecteur de magasin devrait apparaître à gauche, mais le code HTML à droite. Si vous avez vraiment besoin de cette fonctionnalité, vous devez faire appel à la sécurité par opposition à une fonctionnalité qui n’est pas fantastique.

montrer la hiérarchie brisée

Luke Rodgers
la source
0

Même erreur exacte que Tyler sur le correctif PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh de Magento 1.9.2.4

checking file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 129.
2 out of 2 hunks FAILED
Roy Toledo
la source
vérifiez que vous avez installé le correctif précédent. patch 9767 particulier
Rama Chandran M
J'ai vérifié sur www.magereport.com et cela a confirmé que tous les correctifs avaient été installés.9767 également.
Roy Toledo
Je vais vérifier et fournir ans
Rama Chandran M
1
@royToledo Assurez-vous d'avoir également appliqué le correctif SUPEE-9652
Tyler V.
0

Si vous avez un outil de détection de correctif dont vous aurez probablement besoin de modifier la détection SUPEE-9562 car SUPEE-10570modifie le même fichier:

lib/Zend/Mail/Transport/Sendmail.php
Ozie
la source
0

Le patch a été modifié silencieusement par Magento. Ici montré avec le correctif pour Magento 1.8.1.0-1.9.0.1. Sur le premier téléchargement j'ai obtenu le fichier

PATCH_SUPEE-10570_CE_v1.9.0.1_v1-2018-02-23-06-18-06.sh

Quelques jours plus tard, j'ai le fichier suivant

PATCH_SUPEE-10570_CE_v1.9.0.1_v1-2018-02-28-04-54-29.sh

Diff indique que le fichier précédent contient des fichiers de Magento Enterprise Edition contenant la licence incorrecte "Contrat de licence utilisateur final Magento Enterprise Edition". Cela a été corrigé pour "Open Software License (OSL 3.0)".

Feyyer
la source
0

Vous pouvez avoir l'erreur suivante

Hunk #3 FAILED at 17 après la ligne

checking file app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Page/Edit/Tab/Hierarchy.php

Cela m'est arrivé sur la version 1.10.0.2EE de Magento. C'est arrivé parce que le correctif SUPEE-6285 n'a pas été appliqué.

Mukesh
la source