Mage :: log () không hoạt động trên bản cập nhật Magento mới (1.9.4.1)

Sau bản cập nhật mới này (1.9.4.1), Mage :: log () không hoạt động. Rõ ràng, nó có một cái gì đó để làm với Zend_Validate_File_Extensiondòng 819 tại Mage.php nơi nó kiểm tra xem tập tin is_readable()trước khi nó tồn tại. Tôi đã đảo ngược toàn bộ log()phương thức về phiên bản trước đó và nó đang hoạt động trở lại.

Kênh chính mà tôi có thể liên hệ với nhóm Magento để báo cáo vấn đề này là gì?

Bản vá chính thức đến :) Vẫn đang chờ bản vá chính thức ... :(

piotrekk vitaminki đã nhận xét 13 giờ trước

Đây là bản vá chính thức hiện tại sẽ được chuyển sang các phiên bản trước (bản này sẽ hoạt động trên bản mới nhất) https: //gist.github.com/piotrekk vitaminki / 596cae2d25bf467edbd3d3f03ab9f8f

^{Nguồn: https://github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871}

Tôi sẽ tóm tắt mọi thứ tôi tìm thấy cho đến nay dựa trên nghiên cứu và tương tác với Magento cả hỗ trợ và Slack liên quan đến việc vá lỗi với SUPEE-11086. Những gì có thể được thực hiện:

CẬP NHẬT 2: Vấn đề được giải quyết trong SUPCH SUPEE-11155 tiếp theo - https://magento.com/security/patches/supee-11155 . Như mọi khi trước khi áp dụng kiểm tra bản vá cho luồng sự cố có thể xảy ra - Bản vá bảo mật SUPEE-11155 - Sự cố có thể xảy ra? Cảm ơn đến Aad Mathijssen cho nhận xét tuyệt vời.

Cập nhật: Một bản vá chính thức có sẵn theo yêu cầu cho phiên bản EE. Về cơ bản, đó là ý chính của Piotr Kaminski được gói dưới dạng tệp vá Magento.

1. Xóa các thay đổi app/Mage.phptrong tệp vá. Đây là những gì tôi đã làm cho đến nay.
   Ưu điểm - đăng nhập hoạt động như trước.
   Nhược điểm - chỉnh sửa tệp vá, ghi nhật ký không được bảo vệ khỏi khả năng khai thác (nhưng điều này sẽ có rủi ro rất thấp). Khi Magento phát hành bản sửa lỗi chính thức, bạn sẽ phải hoàn nguyên nó và áp dụng Bản vá chưa được chỉnh sửa ban đầu.
2. Thêm một bản vá khác trên đầu dựa trên ý chính của Piotr Kaminski - https://gist.github.com/piotrekk vitaminki / 596cae2d25bf467edbd3d3f03ab9f8f . Piotr Kaminski là một phần của Magento phụ trách an ninh, vì vậy điều này xuất phát trực tiếp từ miệng ngựa. Gist đã được chia sẻ trong Magento slack và có thể sẽ kết thúc với tên SUPEE-11086 v1.1.
   Ưu điểm - Đây là cách Magento
   Nhược điểm - Bạn sẽ phải chờ đợi điều này trở thành chính thức, hoặc chịu trách nhiệm và tự đóng gói nó như một bản vá, điều này sẽ đưa bạn trở lại phải hoàn nguyên một khi bản vá chính thức được đưa ra.
   Một thay đổi nhỏ sẽ là thay vì thêm hai bản vá để chỉnh sửa bản gốc với những thay đổi đó.
3. Chỉnh sửa Zend_Validate_File_Extension::isValidvà xóa xác thực tồn tại tập tin. có một cuộc thảo luận dài trong Magento LTS github - https://github.com/OpenMage/magento-lts/pull/648 . Các isValidphương pháp làm những điều nó không mong đợi để làm, vì vậy một số thành viên đề xuất để sửa chữa nó. Ý kiến ​​của tôi là đây không phải là một giải pháp tốt, có mã là xấu, nhưng nó tồn tại mãi mãi và có thể được sử dụng trong các mô-đun / mã tùy chỉnh. Ngược lại, điều tồi tệ nhất có thể xảy ra là các tệp không được kiểm tra sự tồn tại.
   Ưu điểm - một sửa chữa khá đơn giản
   Nhược điểm - thay đổi tệp thư viện và sửa đổi chức năng của nó.
   Bạn có thể áp dụng điều này như là một bản vá tùy chỉnh hoặc bằng cách viết lại toàn bộ lớp trong nhóm localmã.

Tôi đã chọn chỉnh sửa bản vá và khi v1.1 xuất hiện, tôi sẽ hoàn nguyên bản vá đã chỉnh sửa và áp dụng phiên bản gốc và sau bản sửa lỗi đó. Điều này rất phù hợp với quá trình xây dựng và chính sách nội bộ của chúng tôi, nó có thể khác với bạn. Không có vấn đề gì bạn chọn, tốt hơn là áp dụng bản vá này sớm hơn sau này.

Một cái gì đó từ Đầu vào cộng đồng. Có một Trình xác thực mới được sử dụng Zend_Validate_File_Extension theo bên dưới:

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

"Giải pháp là chỉnh sửa bản vá và chỉ xóa các thay đổi khỏi app / Mage.php. Tôi sẽ không khuyến khích thực hành này, nhưng tình hình rất nghiêm trọng".

Giải pháp tạm thời của tôi đã được sao chép lib/Zend/Validate/File/Extension.phpvào app/code/local/Zend/Validate/File/Extension.phpvà loại bỏ phần này của mã từ isValid()phương pháp:

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

Nó sẽ trở thành ...

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

Khi Magento 1.9.4.2 được phát hành, tôi kiểm tra lại.

Trong thực tế, tệp không thể đọc được hoặc không tồn tại, không có nghĩa là tên tệp không hợp lệ, phải không?

Tôi đề nghị không thay đổi mã lõi và sử dụng bản cập nhật như thế này ( 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';
");

Có một vấn đề khác (có thể được cố tình từ nhóm Magento) ngăn cản khả năng ghi tệp nhật ký bên trong các thư mục con. Ví dụ:

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

Trong các phiên bản trước, cuộc gọi đó sẽ tạo một tệp tại vị trí:

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

Nhưng vì có một basename()hàm gọi trong Mage::log()phương thức, nên tệp được ghi tại:

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

Đây là mã được phân tích trong app/Mage.php:

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

Ngay cả khi nó không liên quan đặc biệt đến 1.9.4.1, vấn đề đã bắt đầu xảy ra gần đây (khoảng các phiên bản 1.9.3.x mới nhất) và rất khó chịu khi bạn phải xử lý nhiều tệp nhật ký, đôi khi có cùng tên ( nhưng ban đầu trong các thư mục con khác nhau).

Vì đoạn mã đó có thể được cố tình từ nhóm Magento, tôi nghĩ rằng không có kế hoạch sửa nó trong một bản phát hành tiếp theo, ngụ ý là hack nó để khôi phục hành vi ban đầu ...