Mage :: log () tidak berfungsi pada pembaruan Magento baru (1.9.4.1)

23

Setelah pembaruan baru ini (1.9.4.1), Mage :: log () tidak berfungsi. Rupanya, itu ada hubungannya dengan Zend_Validate_File_Extensionjalur 819 di Mage.php di mana ia memeriksa apakah file is_readable()sebelum itu bahkan ada. Saya membalikkan seluruh log()metode ke versi sebelumnya dan berfungsi lagi.

Apa saluran utama yang dapat saya hubungi tim Magento untuk melaporkan masalah ini?

rodrigoriome
sumber
1
@PiotrSiejczuk Itu tidak berfungsi untuk file log baru. Komentar kedua Anda menyiratkan bahwa kemampuan untuk mengubah konfigurasi rotasi log menjadikan ini bukan masalah serius dan saya sepenuhnya tidak setuju. Komentar pertama Anda menyiratkan bahwa ini mungkin hanya masalah bagi OP, atau dalam beberapa kasus tepi, dan saya juga sangat tidak setuju dengan itu. Saya benar-benar mengerti mengapa Magento tidak akan memperhatikan bug ini, tetapi implikasi ini adalah kebalikan dari apa yang diperlukan di sini (baik disengaja atau tidak).
toon81
3
Ada banyak situasi di mana ini bermasalah: instalasi bersih (dalam hal ini system.log belum ada), pembuatan / pemasangan modul lokal dan pihak ketiga yang masuk ke file log kustom, konfigurasi logrotate yang tidak secara eksplisit membuat / simpan file log asli.
Aad Mathijssen
3
Ya, logging sangat penting untuk setiap perangkat lunak, saya heran mengapa mereka membiarkannya. Impian saya adalah bahwa ketika tahun 2020 datang dan tim Magento berhenti mendukung 1.x, mereka mengunggah versi terakhir mereka ke repo Git resmi sehingga komunitas dapat terus memperbarui
rodrigoriome
1
@cslogic "Impian saya adalah bahwa ketika tahun 2020 datang dan tim Magento berhenti mendukung 1.x, mereka mengunggah versi terakhir mereka ke repo Git resmi sehingga komunitas dapat tetap memperbarui" "> Sudah selesai dengan OpenMage LTS: github. com / OpenMage / magento-lts
Frédéric MARTINEZ
1
@ FrédéricMARTINEZ itu lucu, Ben Marks benar-benar mengatakan kepada saya tentang repo itu sekitar 30 menit sebelum saya membaca komentar Anda .. Bagaimanapun, terima kasih, akan melihatnya
rodrigoriome

Jawaban:

7

Saya akan meringkas semua yang saya temukan sejauh ini berdasarkan penelitian dan interaksi dengan Magento, baik dukungan dan Slack sehubungan dengan menambal dengan SUPEE-11086. Apa yang bisa dilakukan:

UPDATE 2: Masalah ini teratasi dalam PATCH SUPEE-11155 berikutnya - https://magento.com/security/patches/supee-11155 . Seperti biasa sebelum menerapkan pemeriksaan tambalan untuk kemungkinan masalah utas - Security Patch SUPEE-11155 - Kemungkinan masalah? Terima kasih kepada Aad Mathijssen atas komentarnya yang luar biasa.

Pembaruan: Patch resmi tersedia berdasarkan permintaan untuk versi EE. Pada dasarnya, ini adalah Piotr Kaminski yang dibungkus sebagai file patch Magento.

  1. Hapus perubahan app/Mage.phpdalam file tambalan. Inilah yang telah saya lakukan sejauh ini.
    Pro - logging berfungsi seperti sebelumnya.
    Kontra - mengedit file tambalan, logging tidak terlindungi dari eksploitasi yang mungkin (tapi ini harusnya berisiko sangat rendah). Ketika Magento merilis perbaikan resmi, Anda harus mengembalikannya dan menerapkan Patch asli yang belum diedit.
  2. Tambahkan tambalan lain di atas berdasarkan inti Piotr Kaminski - https://gist.github.com/piotrekkaminski/05/96cae2d25bf467edbd3d3f03ab9f8f . Piotr Kaminski adalah bagian dari Magento yang bertanggung jawab atas keamanan, jadi ini datang langsung dari mulut kuda. Gist dibagikan di Magento slack dan mungkin akan berakhir sebagai SUPEE-11086 v1.1.
    Pro - Ini adalah cara Magento
    Kontra - Anda harus menunggu ini untuk menjadi resmi, atau mengambil tanggung jawab dan mengemasnya sebagai menambal diri Anda sendiri, yang akan membawa Anda kembali untuk harus kembali setelah tambalan resmi selesai.
    Variasi sedikit akan bukannya menambahkan dua tambalan untuk mengedit yang asli dengan perubahan itu.
  3. Edit Zend_Validate_File_Extension::isValiddan hapus validasi keberadaan file. ada diskusi panjang di Magento LTS github - https://github.com/OpenMage/magento-lts/pull/648 . The isValidMetode melakukan hal-hal itu tidak diharapkan untuk dilakukan, sehingga beberapa anggota mengusulkan untuk memperbaikinya. Pendapat saya adalah bahwa ini bukan solusi yang baik, ya kode buruk, tapi itu ada di sana selamanya dan dapat digunakan dalam modul / kode kustom. Sebaliknya, hal terburuk yang dapat terjadi adalah file tidak diperiksa keberadaannya.
    Pro - perbaikan yang agak sederhana
    Kontra - mengubah file perpustakaan dan mengubah fungsinya.
    Anda bisa menerapkan ini sebagai tambalan khusus atau dengan menulis ulang seluruh kelas dalam localkumpulan kode.

Saya memilih untuk mengedit tambalan, dan ketika v1.1 datang saya akan mengembalikan tambalan yang diedit, dan menerapkan versi asli dan setelah perbaikan itu. Ini sesuai dengan proses pembuatan dan kebijakan internal kami, mungkin berbeda untuk Anda. Apa pun yang Anda pilih, lebih baik menerapkan tambalan ini lebih cepat daripada nanti.

Dimitar Ivanov
sumber
1
Pada tanggal 25 Juni, Magento telah merilis SUPEE-11155, Magento Commerce 1.14.4.2 dan Magento Open Source 1.9.4.2 yang mencakup perbaikan untuk masalah ini. Pada dasarnya, tambalan oleh Piotr Kaminski telah dimasukkan.
Aad Mathijssen
4

Sesuatu dari Input Komunitas. Ada Validator baru yang digunakan Zend_Validate_File_Extension sesuai di bawah ini:

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

"Solusinya adalah mengedit tambalan dan hanya menghapus perubahan dari app / Mage.php Saya akan sangat mencegah praktik ini, tetapi situasinya sangat kritis".

Piotr Siejczuk
sumber
Ini memang praktik yang buruk, tetapi saya tidak bisa bertahan tanpa penebangan. Semoga Adobe dapat segera memperbaikinya
rodrigoriome
ya saya harus membuat ulang semua file log karena skrip logrotator menghapus file dan membuat ritsletingnya. Saya perlu menemukan skrip magento yang lebih baik tidak memperbaiki ini.
Kalvin Klien
1
@KalvinKlien: Apakah Anda mencoba dengan: opsi copytruncate dari logrotate? "Potong file log asli ke ukuran nol di tempat setelah membuat salinan, alih-alih memindahkan file log lama dan secara opsional membuat yang baru. Ini dapat digunakan ketika beberapa program tidak dapat diberitahu untuk menutup logfile-nya dan dengan demikian dapat terus menulis ( menambahkan) ke file log sebelumnya selamanya. Perhatikan bahwa ada irisan waktu yang sangat kecil antara menyalin file dan memotongnya, sehingga beberapa data logging mungkin hilang. Ketika opsi ini digunakan, opsi buat tidak akan berpengaruh, karena file log lama tetap ada ".
Piotr Siejczuk
Terima kasih @PiotrSiejczuk! Saya menggunakan ini: / path / var / log / * log {rotate 7 copytruncate kompres harian missingok notifempty}
Kalvin Klien
1

Solusi sementara saya adalah untuk menyalin lib/Zend/Validate/File/Extension.phpke app/code/local/Zend/Validate/File/Extension.phpdan menghapus bagian dari kode dari isValid()metode:

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

Itu akan menjadi ...

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

Ketika Magento 1.9.4.2 dirilis saya periksa lagi.

Faktanya, file tidak dapat dibaca, atau tidak ada, tidak berarti nama file tidak valid, bukan?

Ricardo Martins
sumber
1

Saya sarankan untuk tidak mengubah kode inti dan menggunakan pembaruan seperti ini ( 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';
");
Mehdi Chaouch
sumber
0

Ada masalah lain (yang mungkin disengaja dari tim Magento) yang mencegah kemampuan untuk menulis file log di dalam subfolder. Sebagai contoh:

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

Di versi sebelumnya, panggilan itu akan membuat file di lokasi:

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

Tetapi karena ada metode basename()pemanggilan fungsi Mage::log(), file tersebut ditulis di:

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

Berikut adalah kode yang dicurigai di app/Mage.php:

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

Meskipun tidak terkait dengan 1.9.4.1, masalah mulai terjadi baru-baru ini (sekitar versi 1.9.3.x terbaru) dan sangat menjengkelkan ketika Anda harus berurusan dengan banyak file log, kadang-kadang dengan nama yang sama ( tetapi awalnya di subfolder yang berbeda).

Karena sepotong kode mungkin disengaja dari tim Magento, saya pikir tidak ada rencana untuk memperbaikinya dalam rilis lebih lanjut, yang menyiratkan untuk meretasnya untuk memulihkan perilaku awal ...

Antoine ETIEVANT
sumber
Untuk masalah subfolder itu saya tidak tahu, tetapi untuk masalah logging yang sebenarnya, kami mendukung
rodrigoriome