सुरक्षा पैच SUPEE-11086 - संभव मुद्दे?


24

Magento ने M1 और M1 और M2 के लिए एक नया सुरक्षा पैच जारी किया है।

इन रिलीज़ में महत्वपूर्ण सुरक्षा फ़िक्सेस शामिल हैं। "हम दृढ़ता से अनुशंसा करते हैं कि सभी व्यापारी जल्द से जल्द अपग्रेड करें।"

इस पैच को अपग्रेड या अप्लाई करते समय मुझे किन मुद्दों पर ध्यान देना चाहिए?

Supee-11,086

SUPEE-11086, Magento कॉमर्स 1.14.4.1 और ओपन सोर्स 1.9.4.1 में कई सुरक्षा संवर्द्धन शामिल हैं जो करीब रिमोट कोड निष्पादन (RCE), क्रॉस-साइट स्क्रिप्टिंग (XSS), क्रॉस-साइट अनुरोध जालसाजी (CSRF) और अन्य कमजोरियों को दूर करने में मदद करते हैं।

Magento 2.3.1, 2.2.8 और 2.1.17 सुरक्षा अद्यतन

इन संस्करणों में कई कार्यात्मक और सुरक्षा अपडेट हैं। जोखिम: २.१.१ 2.2, २.२. 2.3 और २.३.१ से पहले Magento वाणिज्य और Magento ओपन स्रोत के लिए महत्वपूर्ण।


रयान Hoerr, मुझे लगता है आप Magento 2.3.1, 2.2.8 और 2.1.17 सुरक्षा अपडेट के लिए एक अलग प्रश्न तैयार करने होंगे
अमित बेरा

2
कोई भी विचार क्यों 1.8.0 / 1.8.1 के लिए कोई संस्करण नहीं है?
जेसन

जवाबों:


20

सबसे बड़ी समस्या, जो पाई गई: Mage::log()गलत तरीके से काम करती है। यदि आप इस फ़ंक्शन को कस्टम लॉग फ़ाइल के साथ कहते हैं (और यह अभी तक मौजूद नहीं है), तो लॉग को फ़ाइल में नहीं लिखा जाएगा, क्योंकि अतिरिक्त सत्यापन के कारण, SUPEE-11086 में जोड़ा गया है।


यह समस्या Magento CE 1.9.4.1 पर भी लागू होती है: magento.stackexchange.com/questions/268229/…
Aad Mathijssen

5
मेरे सभी लॉग पूरी तरह से बंद हो गए। यहां तक ​​कि सिस्टम और अपवाद लॉग। क्या इसे ठीक करने का कोई तरीका है?
काल्विन कालिन

मेरे द्वारा लिखी गई सभी लॉग फाइलें :: लॉग भी बंद हो गई हैं। M1 EE 1.14.0.2
PromInc

एकमात्र समाधान वापस आ गया हैMage::log()
कोडर

3
25 जून तक, Magento ने SUPEE-11155, Magento वाणिज्य 1.14.4.2 और Magento Open Source 1.9.4.2 जारी किया है जिसमें Mage::log()विधि के लिए एक फिक्स शामिल है ।
आरा मत्तीजसेन

11

महत्वपूर्ण: पैच नाम में पैच पर लागू होने वाला उच्चतम संस्करण शामिल है। तो 1.9.3.10 के लिए एक पैच 1.9.3.10, 1.9.3.9, .... एक और पैच के लिए लागू होगा। हम अगली रिलीज में नामकरण में सुधार करने का प्रयास करेंगे और आप https://github.com/steverobbins/magedownload-cli का भी उपयोग कर सकते हैं क्योंकि यह एपीआई पर संस्करणों मेटाडेटा को ठीक से देखना चाहिए।


5

दूसरों की तरह, मेरे पास लॉग फ़ाइलें पूरी तरह से डेटा लिखना बंद कर देती हैं।

बग का स्रोत - लॉग फ़ाइल डेटा लेखन नहीं है

में app/Mage.phpवे यह बदलाव किया है:

         // Validate file extension before save. Allowed file extensions: log, txt, html, csv
         -        if (!self::helper('log')->isLogFileExtensionValid($file)) {
         +        $_allowedFileExtensions = explode(
         +            ',',
         +            (string) self::getConfig()->getNode('dev/log/allowedFileExtensions', Mage_Core_Model_Store::DEFAULT_CODE)
         +        );
         +        $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);
         +        $logDir = self::getBaseDir('var') . DS . 'log';
         +        if (!$logValidator->isValid($logDir . DS . $file)) {
                 return;
             }

जो स्वीकृत फ़ाइल एक्सटेंशन की अल्पविराम से अलग की गई सूची के लिए विन्यास को देख रहा है। हालांकि उन्होंने इस सूची को विन्यास में नहीं जोड़ा था - हमारे लिए इसे स्वयं कॉन्फ़िगर करने के लिए Mage Admin में एक विकल्प भी नहीं।

बग का समाधान - लॉग फ़ाइल डेटा लेखन नहीं

इसे हल करने के लिए, बस core_config_dataतालिका में डेटाबेस में एक प्रविष्टि करें ।

INSERT INTO core_config_data VALUES ( NULL, 'default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv' );

वस्तुओं को कैश के रूप में अच्छी तरह से साफ़ करें और आपको एक बार फिर लॉग फ़ाइलों में डेटा लेखन देखना चाहिए।

ls -lrt var/log/ | tail


संदर्भ के लिए, यह मुद्दा ईई 1.14.2.0 पर था जिसमें सभी सुरक्षा पैच लगाए गए थे।

मैंने इस मुद्दे पर Magento के समर्थन के साथ एक टिकट खोला लेकिन अभी तक किसी तकनीशियन से प्रतिक्रिया नहीं मिली है। मैं कतार में हूं।


इस बग के बारे में मुझे वास्तव में भ्रमित करता है कि मैगेंटो के पास लॉग फ़ाइल एक्सटेंशन को मान्य करने के लिए पहले से ही एक विधि है जिसे उन्होंने 2017 के अंत में SUPEE-10415 के माध्यम से जोड़ा था।

app/code/core/Mage/Log/Helper/Data.php

    /**
     * Checking if file extensions is allowed. If passed then return true.
     *
     * @param $file
     * @return bool
     */
    public function isLogFileExtensionValid($file)
    {
        $result = false;
        $validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);
        if ($validatedFileExtension && in_array($validatedFileExtension, $this->_allowedFileExtensions)) {
            $result = true;
        }

        return $result;
    }

उन्होंने उस तर्क का पुन: उपयोग क्यों नहीं किया, जो लॉग व्हील के अधूरे पुन: आविष्कार का प्रयास करता है?


3
यह सही नहीं है। एप्लिकेशन / etc / config.xml में अनुमतिकैटेक्स्टेंशन को कॉन्फ़िगरेशन के रूप में जोड़ा गया है। यदि यह डेटाबेस में मौजूद नहीं है तो इसका उपयोग किया जाएगा। वास्तविक समस्या यह है कि नया सत्यापन फ़ंक्शन पहले यह देखने की कोशिश करता है कि क्या फ़ाइल पहले से मौजूद है, जो शायद बहुत स्वागत योग्य नहीं है।
Ren Schep

यह इंगित करने के लिए धन्यवाद कि @ RenéSpp मैं उस पैच में अब परिवर्तन देख रहा हूं। गहराई से देखने पर, मेरे config.xml फ़ाइल हमारे कोड बेस के बाकी हिस्सों के रूप में एक अलग रिपॉजिटरी में रहती है। इस कारण से जब मैंने इस पैच के लिए परिवर्तन को धक्का दिया तो इस बदलाव के साथ कॉन्फिगर फाइल अपडेट नहीं की गई। गैर-मौजूद फ़ाइलों के लिए नहीं लिखने के लिए, मैं व्यक्तिगत रूप से अपने सर्वर पर काम करने के लिए खोज रहा हूं। मुझे आश्चर्य होता है कि क्या यह फ़ाइल-सिस्टम पर एक फ़ोल्डर अनुमतियाँ समस्या है। मैं हालांकि उस कोड में बहुत गहरा नहीं देखा है।
PromInc

मैंने जो परीक्षण किया है, वह यह है कि यदि फ़ाइल पहले से मौजूद है तो यह काम करता है। यदि फ़ाइल पठनीय है तो पहला चेकवैलिड चेक होता है। यदि यह मौजूद नहीं है, तो फ़ाइल बनाने का कोई प्रयास नहीं है और एक गलत लौटाया जाता है।
Ren Schep

@ Renéchep तो हम इसे कैसे ठीक करते हैं? Magento समर्थन एक ** एच में दर्द है। वे जवाब देने में बहुत धीमी हैं।
आदर्श खत्री

@ AdarshKhatri को मैगेंटो को लिखने से पहले फाइल बनाने की जरूरत है। स्पर्श करें /path/to/magento/install/html/var/log/newlogfile.log
PromInc

4

Mage::log()लॉग फ़ाइलों के लिए कुछ भी लिखने में विफल रहता है अगर वे शुरू में मौजूद नहीं हैं। यह कॉल करते समय नहीं मिली त्रुटि isValidको Zend_Validate_File_Extensionफेंकने के कार्य के कारण है Zend_Loader::isReadable($value)isValidलॉग फ़ाइल के वास्तव में बनाए जाने के बाद मैंने कोशिश / पकड़ में अस्थायी रूप से इसे ठीक कर लिया है और सत्यापन विफल होने पर फ़ाइल को हटा रहा है:

<?php
final class Mage
{
    ...
    public static function log($message, $level = null, $file = '', $forceLog = false)
    {
        ...

        try {
            if (!isset($loggers[$file])) {
                $logFile = $logDir . DS . $file;

                if (!is_dir($logDir)) {
                    mkdir($logDir);
                    chmod($logDir, 0750);
                }

                if (!file_exists($logFile)) {
                    file_put_contents($logFile, '');
                    chmod($logFile, 0640);
                }

                if (!$logValidator->isValid($logFile)) {
                    unlink($logFile);

                    return;
                }

        ...
    }
}

यह निश्चित रूप से एक अस्थायी समाधान है जब तक कि हमारे पास कुछ अधिक ठोस न हो


3

पैचिंग 1.9.3.10 के साथ संभव मुद्दा

checking file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
Hunk #1 FAILED at 57.
1 out of 1 hunk FAILED

हमारे पास पैच में:

diff --git app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
index 8d3c526c280..fde2ef0d45d 100644
--- app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
+++ app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
@@ -57,7 +57,7 @@ class Mage_Adminhtml_Block_Customer_Group_Edit extends Mage_Adminhtml_Block_Widg
                 'form_key' => Mage::getSingleton('core/session')->getFormKey()
             ));
         } else {
-            parent::getDeleteUrl();
+            return parent::getDeleteUrl();
         }
     }

हालाँकि, 1.9.3.10 पर कोड (mage LTS के माध्यम से) मैं उस कोड को प्रश्न में नहीं देखता:

https://github.com/OpenMage/magento-lts/blob/1.9.3.x/app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php

लेकिन, यह 1.9.4 के लिए मौजूद है

https://github.com/OpenMage/magento-lts/blob/1.9.4.x/app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php

संभावित कारण पहले से लागू नहीं एक लापता पैच है।


4
आपको पैच SUPEE-10975 याद आ रहा है।
रिचर्ड फेरारो

mmm, मेरे पैच सेट के अनुसार, जो पहले से ही लागू है: 2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Thu Nov 8 13:45:47 2018 +0200 | CE-1.9.3.10-देव
प्रोगब्लू

नवीनतम पैच का फ़ाइल नाम PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-14-14-43.sh है, जबकि आपका अंतिम Nov 8, 2018 को जारी होना प्रतीत होता है जो नवीनतम I suppose नहीं है।
रिचर्ड फेरारो

1
मैंने PATCH_SUPEE-10975 को वापस कर दिया और फिर से आवेदन किया, फिर से नवीनतम लागू किया, सभी ने काम किया
ProxiBlue

यह SUPEE-10975 में एक बग था, जिसके कारण आप ग्राहक समूह को हटा नहीं पाए। ऐसा लगता है कि आपने इसे मैन्युअल रूप से ठीक कर दिया है, जिससे यह नया पैच विफल हो जाता है जो इसे ठीक भी कर रहा है।
रेने शेप

3

मैगेंटो 1.9.0.1 पर PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh का उपयोग कर पैच को स्थापित करने की कोशिश कर रहा हूं।

Hunk #1 FAILED at 141.
1 out of 1 hunk FAILED

मैंने निम्नलिखित कोड को 'ऐप / etc / config.xml' से हटाकर फिर से पैच को चलाया

<dev>
    <template>
        <allow_symlink>0</allow_symlink>
    </template>
</dev>

3

मैं M1 पैच के नामकरण को लेकर थोड़ा भ्रमित हूं।

पुराने पैच के लिए उन्होंने उन्हें पसंद किया SUPEE-10975 for CE 1.9.3.4-1.9.3.10या SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB)अब केवल एक संस्करण को संबोधित कर रहे हैं PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh

क्या वर्तमान पैच एक मामूली रिलीज के सभी रिलीज को संबोधित कर रहा है या केवल आखिरी है?

मैंने 1.9.3.1 स्टोर के साथ एक परीक्षण किया और सब कुछ गुजर गया, लेकिन यह सुनिश्चित नहीं किया कि क्या अन्य रिलीज के लिए सटीक है?


धन्यवाद रयान! Thats ने @ajon सवाल का जवाब दिया "किसी भी विचार में 1.8.0 / 1.8.1 के लिए कोई संस्करण क्यों नहीं है?" उसके लिए उसे 1.7.0.2 पैच के साथ जाना चाहिए, है ना? नहीं पता था कि पहले कई छोटे रिलीज को संबोधित करने वाले पैच थे।
सेबस्टियन

2
आपको यकीन है @RyanHoerr? क्या यह विपरीत नहीं है, क्योंकि यह एक और धागा magento.stackexchange.com/questions/267576 ... पर प्रकल्पित है ? ऐसा लगता है कि, यदि हम पुराने नामकरण शैली से अनुमान लगाते हैं, तो PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-03-02-36.sh 1.7.0.0 से 1.7.0.2 तक लागू किया जा सकता है, और इसी तरह, प्रत्येक पैच में संस्करण संख्या उस मामले में अंतिम होगी । Magento से कोई भी पुष्टि कर सकता है कि उस नई नामकरण शैली के पीछे क्या तर्क है ? अग्रिम में Thx ..
एंटोनी Kociuba

2
मैं @AntoineKociuba के साथ 2 अलग 1.8.1 स्टोर्स के साथ जाऊंगा, जो 4 में चलता है, जो 1.7.0.2 पैच के साथ फेल होता है: - ऐप / कोड / कोर / मैज / यूएसए / आदि / system.xml हंक # 4 845 - ऐप के साथ फेल हुआ। /etc/config.xml हंक # 1 144 पर आये - app / locale / en_US / Mage_Widget.csv हंक # 6 पर 6 फेल - lib / Varien / Filter / खाका हंक # 2 फेल # 254 पर जबकि 1.9.1.0 रन सुचारू रूप से। 1.9.3.1 स्टोर के साथ समान: पैच 1.9.2.4 doenst काम करता है जबकि 1.9.3.10 करता है।
सेबेस्टियन

3
@RyanHoerr यह गलत है। नाम में नवीनतम संस्करण शामिल है जिसे पैच लागू होता है। तो 1.9.3.10 के लिए एक पैच 1.9.3.10, 1.9.3.9, .... एक और पैच के लिए लागू होगा। हम अगली रिलीज में नामकरण में सुधार करने की कोशिश करेंगे और आप github.com/steverobbins/magedownload-cli का भी उपयोग कर सकते हैं क्योंकि यह एपीआई पर संस्करणों मेटाडेटा को ठीक से देखना चाहिए।
पिओत्र कमिंसकी

मेरी बुरी जानकारी निकाल दी। सुधारों के लिए धन्यवाद।
रयान होरे

2

Magento 1.9 में लॉगिंग टूट गया। SUPEE-11086 पैच में लॉगिंग को ठीक करने के लिए:

ऐप में / Mage.php:

-        $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);
         $logDir = self::getBaseDir('var') . DS . 'log';
-        if (!$logValidator->isValid($logDir . DS . $file)) {
+        $validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);
+        if (!$validatedFileExtension || !in_array($validatedFileExtension, $_allowedFileExtensions)) {

संसाधन: https://gist.github.com/piotrekk विटामिन 0596cae2d25bf467edbd3d3f03ab9f8f

आशा है कि ये आपकी मदद करेगा!


1

M1 के लिए पैच में सभी नई PHP फ़ाइलों में गैर-संसाधित टेम्पलेट संस्करण हैं

<?php
/**
 * {license_notice}
 *
 * @copyright   {copyright}
 * @license     {license_link}
 */

कोई मुद्दा नहीं है लेकिन गलत लग रहा है। SUPEE-10975 के बाद मेरी भी यही भावना थी।


1

मैंने लॉग फ़ाइलों के साथ एक समस्या देखी है जो अब नहीं बनाई जा रही है और केवल लॉग फ़ाइल पहले से मौजूद होने पर बाहर लिखा जा रहा है। यह लाइन के कारण लगता है:

if (!$logValidator->isValid($logDir . DS . $file)) {

app / Mage.php से। मैंने पुराने तर्क का उपयोग करके इसे ठीक किया। तो ऊपर दी गई पंक्ति को निम्नलिखित के साथ बदलें:

if (!self::helper('log')->isLogFileExtensionValid($file)) {

0

फ़ाइल ऐप / कोड / कोर / मैज / एडमिनकैम / ब्लॉक / ग्राहक / समूह / संपादन। चेक हंक # 1 पर 57 फेल्ड। 1 में से 1 हंक फेल्ड

पैच 10975 में इस बिंदु पर एक त्रुटि थी। रिटर्न स्टेटमेंट गायब था। हो सकता है कि आपने पैच 10975 लगाने या बदलाव को नज़रअंदाज़ करने के बाद इस बग को ठीक कर दिया हो। बग को 11086 में तय किया गया था। यदि कोड की इस पंक्ति को पहले से ही आपके द्वारा समायोजित / अनदेखा किया गया है, तो यह नए पैच को लागू करते समय आपके द्वारा वर्णित त्रुटि के परिणामस्वरूप होगा। यदि आपने पहले ही बग को ठीक कर लिया है, तो बस पैच फाइल में ब्लॉक को हटा दें और पैच को फिर से चलाएं।


1
मैं Supee-11,086 काम करने के लिए के लिए "कम आधिकारिक" पैच Supee-11043 वापस लौटने के लिए था
MageHost - जेरोन वर्म्यूलेन

0

SUPEE-11086 का उपयोग करना | CE_1.9.1.0 जैसा कि ऊपर रयान होरे ने सुझाया है।

SUPEE-11086 लागू करना | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | शुक्र मार 22 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

CE_1.9.2.1 को

मुझे प्रत्येक फ़ाइल पर एक विफलता मिलती है।

मैंने पैच को अन्य रिपॉजिट पर सफलतापूर्वक लागू किया है।

कोर कोड अछूता।

लागू पैच की सूची

SUPEE-6788
SUPEE-7405-CE-1-9-2-2
SUPEE-7405 
SUPEE-8788 
SUPEE-9652 
SUPEE-8967 
PATCH_SUPEE-9767_CE_1.9.3.0_v2
SUPEE-10266-CE-1.9.2.4
SUPEE-10415-ce-1.9.2.1
SUPEE-10570_CE_v1.9.2.2
SUPEE-10570_CE_v1.9.2.2
SUPEE-10570_CE_v1.9.2.2
SUPEE-10752_CE_v1.9.2.4
SUPEE-10888_CE_v1.9.2.4
SUPEE-10975_CE_v1.9.3.3

धन्यवाद @AntoineKociuba स्पष्टीकरण के लिए। मैंने सत्यापित किया है कि पिछले पैच सभी सही हो गए हैं, लेकिन जब मैं अपने 1.9.2.1 इंस्टॉलेशन के लिए PATCH_SUPEE-11086_CE_1.9.2.4_v1 के नीचे बताए अनुसार सही पैच लागू करता हूं, तो मुझे अभी भी एक त्रुटि मिल रही है, लेकिन एक हंक। क्या आप एक मैनुअल पैच सुझाएंगे?
बेवन होलमैन

आप किस हंक पर असफल हो रहे हैं?
रेने शेप

यह हल हो गया है, मुझे रेपो का एक नया क्लोन प्राप्त करना था। धन्यवाद रेने
बेवन होल्मन

0

M1.9.3.7 पैच PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh के मुद्दे

checking file app/Mage.php
checking file app/code/core/Mage/Admin/Model/Session.php
checking file app/code/core/Mage/Adminhtml/Block/Api/Buttons.php
checking file app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit.php
checking file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
Hunk #1 FAILED at 57.
1 out of 1 hunk FAILED
checking file app/code/core/Mage/Adminhtml/Block/Permissions/Buttons.php
checking file app/code/core/Mage/Adminhtml/Block/System/Design/Edit.php
checking file app/code/core/Mage/Adminhtml/Block/System/Store/Edit.php
checking file app/code/core/Mage/Adminhtml/Controller/Action.php
checking file app/code/core/Mage/Adminhtml/Helper/Data.php
checking file app/code/core/Mage/Adminhtml/Model/Email/PathValidator.php
checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED

एप्लिकेशन / कोड / कोर / Mage / Adminhtml / ब्लॉक / ग्राहक / समूह / Edit.php के रूप में देखना विफल रहा। मुझे लगता है कि आपने पैच SUPEE-11043 लागू किया है, जो SUPEE-11086 आपने नहीं किया है।
रेने शेप

0

लागू करने का प्रयास करते समय किसी समस्या की पुष्टि कर सकते हैं SUPEE-11086 1.9.1.1 के नए डाउनलोड और पूरी तरह से पैच किए गए संस्करण पर जाता है, जिसमें एडमिन डैशबोर्ड चार्ट पैच सहित सब कुछ शामिल है और शामिल है -MPERF-10509-CE-2019-03-13-06-31-24.diff

पैच निम्न फ़ाइलों में विफल रहता है।

app/code/core/Mage/Adminhtml/Block/Api/Buttons.php
app/code/core/Mage/Adminhtml/Block/Permissions/Buttons.php
app/code/core/Mage/Api2/Block/Adminhtml/Roles/Buttons.php

इन फ़ाइलों में v1.9.1.1 डाउनलोड की प्रारंभिक प्रतिबद्धता से कोई बदलाव नहीं हुआ है। 1.9.2.4 से फ़ाइलों की प्रतिलिपि बनाना, SUPEE-11086 को लागू करना और फिर v1.9.4.1 स्रोत के साथ तुलना करना वे अब मेल खाते हैं।

Magento v1.9.1.1 लगता है एक बच्चे की समस्या का एक सा हो ...


मैंने सिर्फ 1.9.1.4 पैच के साथ 1.9.2.4 पैच की तुलना की। और ऐसा लगता है कि इन पैच के बीच अंतर 3 फाइलें हैं जिनका आप उल्लेख करते हैं। तो ऐसा लगता है कि 1.9.1.0 पर 1.9.1.0 पैच का उपयोग किया जाना चाहिए।
रेने शेप

0

लागू करने का प्रयास करते समय किसी समस्या की पुष्टि कर सकते हैं SUPEE-11086 1.9.3.0 के एक नए डाउनलोड किए गए और पूरी तरह से पैच किए गए संस्करण पर जाता है, जिसमें एडमिन डैशबोर्ड चार्ट पैच सहित सब कुछ शामिल है और शामिल है -MPERF-10509-CE-2019-03-13-06-31-24.diff

पैच एप्लिकेशन / config.xml में विफल रहता है क्योंकि नीचे नोड गायब है। SUPEE-11086 चलाने से पहले नोड जोड़ें, कोई समस्या नहीं।

<config>
    </default>
        <dev>
            <template>
                <allow_symlink>0</allow_symlink>
            </template>
        </dev>
    </default>
</config>

0

मैंने मॉडल के साथ एक नया मुद्दा खोजा Mage_Eav_Model_Attribute_Data_File

ग्राहकों की इकाई पर, मैंने फ़ाइल अपलोड विशेषताएँ जोड़ी हैं। इन विशेषताओं की आवश्यकता नहीं है, और जब मैं एक नया अपलोड किए बिना किसी फ़ाइल को हटाना चाहता हूं, तो विलोपन काम नहीं कर रहा है, क्योंकि नई विधि के माध्यम से विशेषता मान मान्य नहीं हैsetAttributeValidationAsPassed()

जल्दी ठीक किया है मैं विधि में है validateValue($value)

if (!$attribute->getIsRequired() && !$toUpload) {
    $attribute->setAttributeValidationAsPassed(); // this new line is added 
    return true;
}

यह समस्या तब से सभी Magento 1.x रिलीज़ में मौजूद है SUPEE-11086


0

मैगेटो 1.9.3.1

पैच PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh का उपयोग करके CE 1.9.3.1 को पैच करने की कोशिश करते समय समस्या उत्पन्न हुई:

checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.