Mage :: log () ไม่ทำงานกับ Magento update ใหม่ (1.9.4.1)

หลังจากอัปเดตใหม่นี้ (1.9.4.1) Mage :: log () ไม่ทำงาน เห็นได้ชัดว่ามันมีบางอย่างZend_Validate_File_Extensionเกี่ยวกับon line 819 ที่ Mage.php ซึ่งจะตรวจสอบว่าไฟล์is_readable()ก่อนหน้านั้นมีอยู่จริงหรือไม่ ฉันย้อนกลับlog()วิธีการทั้งหมดเป็นรุ่นก่อนหน้าและทำงานได้อีกครั้ง

ช่องทางหลักที่ฉันสามารถติดต่อทีม Magento เพื่อรายงานปัญหานี้คืออะไร

เป็นทางการมาแก้ไขแพทช์ :)ยังคงรอแพทช์ทางการ ...

piotrekkaminski แสดงความคิดเห็น 13 ชั่วโมงที่แล้ว

นี่คือแพทช์อย่างเป็นทางการในปัจจุบันที่จะได้รับการแจ้งความกับรุ่นก่อนหน้านี้ (ซึ่งควรจะทำงานในล่าสุด) https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

^{ที่มา: https://github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871}

ฉันจะสรุปทุกอย่างที่ฉันพบจากการวิจัยและการมีปฏิสัมพันธ์กับ Magento ทั้งการสนับสนุนและ Slack ที่เกี่ยวข้องกับการปะแก้ด้วย SUPEE-11086 สิ่งที่สามารถทำได้:

UPDATE 2: ปัญหาได้รับการแก้ไขในแพทช์ต่อไปสุภี-11155 - https://magento.com/security/patches/supee-11155 เช่นเคยก่อนที่จะใช้การตรวจสอบโปรแกรมแก้ไขสำหรับเธรดปัญหาที่เป็นไปได้ - Security Patch SUPEE-11155 - ปัญหาที่เป็นไปได้หรือไม่ ขอบคุณไปAad Mathijssenสำหรับความคิดเห็นที่ดี

อัปเดต: แพทช์อย่างเป็นทางการมีให้บริการตามความต้องการสำหรับรุ่น EE โดยทั่วไปมันเป็นส่วนสำคัญของ Piotr Kaminski ห่อเป็นไฟล์วีโอไอพีแก้ไข

1. ลบการเปลี่ยนแปลงapp/Mage.phpในไฟล์แพทช์ นี่คือสิ่งที่ฉันได้ทำไปแล้ว
   ข้อดี - การบันทึกทำงานเหมือนก่อน
   ข้อด้อย - การแก้ไขไฟล์แพทช์การบันทึกไม่ได้รับการป้องกันจากการหาประโยชน์ที่เป็นไปได้ เมื่อ Magento เผยแพร่การแก้ไขอย่างเป็นทางการคุณจะต้องเปลี่ยนกลับคืนและใช้ Patch ที่ไม่มีการแก้ไขดั้งเดิม
2. เพิ่มแพทช์อีกด้านบนขึ้นอยู่กับเค้า Piotr มินสกี - https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f Piotr Kaminski เป็นส่วนหนึ่งของ Magento ในด้านความปลอดภัยดังนั้นสิ่งนี้จึงมาจากปากม้า สรุปสาระสำคัญแบ่งปันใน Magento หย่อนและอาจจะสิ้นสุดในฐานะ SUPEE-11086 v1.1
   ข้อดี - นี่คือวิธีวีโอไอพี
   ข้อด้อย - คุณจะต้องรอให้สิ่งนี้กลายเป็นทางการหรือรับผิดชอบและบรรจุเป็นแพตช์ด้วยตัวคุณเองซึ่งจะนำคุณกลับไปสู่การเปลี่ยนคืนเมื่อแพทช์อย่างเป็นทางการขึ้น
   ความแตกต่างเล็กน้อยจะเป็นการแทนที่การเพิ่มแพตช์สองตัวเพื่อแก้ไขอันเดิมที่มีการเปลี่ยนแปลงเหล่านั้น
3. แก้ไขZend_Validate_File_Extension::isValidและลบการตรวจสอบความมีอยู่ของไฟล์ มีการอภิปรายที่ยาวนานในวีโอไอพี LTS GitHub - https://github.com/OpenMage/magento-lts/pull/648 isValidวิธีการทำสิ่งที่มันไม่ได้คาดว่าจะทำอย่างไรจึงสมาชิกบางคนเสนอให้แก้ไขได้ ความคิดเห็นของฉันคือว่านี่ไม่ใช่ทางออกที่ดีใช่รหัสไม่ดี แต่มันมีตลอดไปและอาจใช้ในโมดูล / รหัสที่กำหนดเอง ในทางตรงกันข้ามที่เลวร้ายที่สุดที่อาจเกิดขึ้นคือไฟล์จะไม่ถูกตรวจสอบสำหรับการดำรงอยู่
   ข้อดี - แก้ไขค่อนข้างง่าย
   ข้อเสีย - เปลี่ยนไฟล์ไลบรารีและแก้ไขการทำงานของมัน
   คุณสามารถใช้สิ่งนี้เป็นแพทช์ที่กำหนดเองหรือโดยการเขียนคลาสทั้งหมดในกลุ่มlocalรหัส

ฉันเลือกที่จะแก้ไขแพตช์และเมื่อ v1.1 มาฉันจะกลับไปแก้ไขแพทช์แก้ไขและใช้เวอร์ชันดั้งเดิมและหลังจากการแก้ไขนั้น สิ่งนี้เหมาะสมกับกระบวนการสร้างและนโยบายภายในของเราซึ่งอาจแตกต่างกันสำหรับคุณ ไม่ว่าคุณจะเลือกแบบไหนดีกว่าที่จะใช้โปรแกรมแก้ไขนี้เร็วกว่าในภายหลัง

บางอย่างจากอินพุตชุมชน มี Validator ใหม่ที่ใช้ Zend_Validate_File_Extension ดังต่อไปนี้:

https://github.com/brentwpeterson/magento-patches/blob/master/CE1.9/PATCH_SUPEE-11086_CE_1.9.4.0_v1-2019-03-26-03-05-04.sh#L183

"ทางออกคือการแก้ไขแพตช์และเพียงแค่ลบการเปลี่ยนแปลงจาก app / Mage.php ฉันจะไม่สนับสนุนการปฏิบัตินี้ แต่สถานการณ์มีความสำคัญ"

แก้ปัญหาชั่วคราวของฉันคือการคัดลอกlib/Zend/Validate/File/Extension.phpไปapp/code/local/Zend/Validate/File/Extension.phpและเอาส่วนหนึ่งของรหัสจากนี้isValid()วิธีการ:

    // Is file readable ?
    #require_once 'Zend/Loader.php';
    if (!Zend_Loader::isReadable($value)) {
        return $this->_throw($file, self::NOT_FOUND);
    }

มันจะกลายเป็น ...

public function isValid($value, $file = null)
{
    if ($file !== null) {
        $info['extension'] = substr($file['name'], strrpos($file['name'], '.') + 1);
    } else {
        $info = pathinfo($value);
...

เมื่อ Magento 1.9.4.2 ออกมาฉันจะตรวจสอบอีกครั้ง

อันที่จริงไฟล์ไม่สามารถอ่านได้หรือไม่มีอยู่ไม่ได้หมายความว่าชื่อไฟล์ไม่ถูกต้องใช่ไหม

ฉันไม่แนะนำให้เปลี่ยนรหัสหลักและใช้การอัปเดตเช่นนี้ ( https://gist.github.com/mehdichaouch/99c67298b5a65f81219c9b69942b6fe7 )

$installer->run("
    INSERT INTO `{$installer->getTable('core_config_data')}` (scope, scope_id, path, value)
    VALUES ('default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv')
    ON DUPLICATE KEY UPDATE value = 'log,txt,html,csv';
");

มีปัญหาอื่น (ซึ่งอาจพิจารณาจากทีมวีโอไอพี) ซึ่งป้องกันไม่ให้ความสามารถในการเขียนไฟล์บันทึกในโฟลเดอร์ย่อย ตัวอย่างเช่น:

Mage::log('Some log information', Zend_Log::DEBUG, 'somefolder/anotherfolder/somelogfile.log', true);

ในเวอร์ชันก่อนหน้าการโทรนั้นจะสร้างไฟล์ที่ตำแหน่ง:

/your-magento-app-root-folder/var/log/somefolder/anotherfolder/somelogfile.log

แต่เนื่องจากมีการbasename()เรียกใช้ฟังก์ชันในMage::log()เมธอดไฟล์จึงถูกเขียนที่:

/your-magento-app-root-folder/var/log/somelogfile.log.

นี่คือรหัสที่ถูกกล่าวหาในapp/Mage.php:

$file = empty($file) ?
    (string) self::getConfig()->getNode('dev/log/file', Mage_Core_Model_Store::DEFAULT_CODE) : basename($file);

แม้ว่าจะไม่เกี่ยวข้องกับ 1.9.4.1 โดยเฉพาะปัญหาก็เริ่มเกิดขึ้นเมื่อเร็ว ๆ นี้ (ประมาณเวอร์ชัน 1.9.3.x ล่าสุด) และน่ารำคาญมากเมื่อคุณต้องจัดการกับไฟล์บันทึกจำนวนมากบางครั้งมีชื่อเดียวกัน ( แต่เริ่มแรกในโฟลเดอร์ย่อยที่แตกต่างกัน)

เนื่องจากโค้ดดังกล่าวน่าจะได้รับการพิจารณาจากทีมวีโอไอพีฉันคิดว่าไม่มีแผนที่จะแก้ไขในรีลีสต่อไปซึ่งหมายถึงการแฮ็คเพื่อคืนค่าพฤติกรรมเริ่มต้น ...