Patch atau Core Hack


14

Ketika saya sedang dalam proyek peningkatan sistem, salah satu hal yang saya lakukan adalah membedakan sistem klien dengan instalasi Magento yang baru. Saya mencari peretasan inti atau file tambahan yang bukan bagian dari Magento standar untuk memastikan saya menangkap pekerjaan buruk tapi bisnis-kritis yang dilakukan oleh freelancer, kontraktor, konsultan, atau agensi sebelumnya.

Satu hal yang selalu mengejutkan saya adalah tambalan. Selama bertahun-tahun Magento telah mengeluarkan tambalan "antar versi" - biasanya untuk mengatasi perbaikan keamanan, atau perubahan API pengiriman / pembayaran vendor.

Masalahnya adalah, dari sudut pandang diff, tambalan tidak dapat dibedakan dari peretasan inti - terutama ketika Anda tidak tahu tambalan mana (jika ada) yang telah diterapkan pada sistem.

Yang mengarah ke pertanyaan saya.

Bagaimana Anda membedakan antara hack inti dan patch?

Jawaban:


16

Patch Magento yang disediakan oleh dukungan akan menambahkan semacam log untuk app/etc/applied.patches.list. Saya tidak tahu kapan atau berapa lama tambalan "skrip" telah melakukan ini. Patch CE juga tampaknya melakukan ini.


Rapi! Saya tidak tahu hal itu. Apakah Anda tahu apakah ini bagian dari .patch yang sebenarnya - atau apakah dukungan melakukannya secara manual? Atau (mungkin?) Keduanya? Melihat beberapa file .patch lama dan tidak melihat perubahan apa pun pada file yang diterapkan.patches.list.
Alan Storm

Self membantu yang terakhir - tambalan CE melakukan ini secara otomatis (lihat: magentocommerce.com/index.php/getmagento/ce_patches/… )
Alan Storm

2
Tampaknya (dan @ joshua-s-warren tampaknya mengkonfirmasi) bahwa tidak semua file tambalan dibuat sama. Jika kami "beruntung" tambalan akan memiliki fungsionalitas ini. Berikut ini adalah contoh tambalan yang memilikinya: magentocommerce.com/index.php/getmagento/ce_patches/... Ini juga hanya mencantumkan file yang diubah dan bukan perubahannya. Anda harus mencoba melacak tambalan untuk mengetahui apa yang berubah, meskipun tidak ada "jaminan" itu yang sama digunakan.
beeplogic

2
Sayangnya sebagian besar patch EE yang kita punya, tidak memiliki fungsi ini
Allan MacGregor

4
Semua tambalan yang didistribusikan sebagai file .sh, untuk tiket SUPEE harus memiliki fungsi ini (kecuali yang lama). @ AllanMacGregor Terkejut Anda tidak melihatnya. Apakah Anda memiliki contoh tambalan yang telah diterapkan (nomor SUPEE) tetapi tidak terdaftar?
Piotr Kaminski

7

Ini adalah sesuatu yang sering saya tangani (dan saya sedang kerjakan sekarang), dan sayangnya, sejauh ini ini adalah proses yang sepenuhnya manual - kami memiliki proses otomatis yang menandai setiap file yang dapat dimodifikasi sebagai bagian dari audit otomatis awal kami untuk klien dukungan baru. Kami kemudian meminta seseorang untuk membedakan file-file itu, dan mengesampingkan setiap false positive yang jelas (yaitu, perubahan spasi putih).

Kemudian, bagian yang menyenangkan - seorang anggota senior dari tim kami yang telah bekerja dengan Magento untuk beberapa waktu harus melihat hasil untuk menentukan apakah ada file yang dimodifikasi dapat menjadi hasil tambalan. Kami telah melihat memperbarui sistem kami untuk memeriksa semua tambalan yang kami ketahui / dapat kami tangani, dan itu mungkin bekerja untuk CE, tetapi pada EE itu bahkan lebih menantang, karena dukungan EE terkadang mengeluarkan tambalan secara langsung untuk klien yang tidak pernah dirilis dengan cara lain atau katalog secara konsisten.

Jadi, ketika kita melakukan tinjauan tingkat ini, kita mengandalkan pengalaman masa lalu menerapkan tambalan ini + akal sehat (yaitu, apakah itu hanya perubahan ke titik akhir API? Jika demikian, apakah titik akhir yang diubah hadir dalam versi yang diperbarui? Jika demikian, itu tambalan dan dapat diabaikan).

Secara teori akan sangat mudah untuk menerapkan semua tambalan yang tersedia di halaman unduhan CE, dll., Untuk setiap versi CE yang berlaku dan memeriksa hal tersebut (FYI, kami tidak menggunakan diff untuk pass pertama - kami menggunakan hashing, di sebagian karena kami membuat teknologi ini menjadi alat yang dapat memeriksa situs dari jarak jauh tanpa perlu mengunduhnya terlebih dahulu). Itu akan mengesampingkan sebagian besar tambalan, tetapi masih tidak membantu untuk tambalan CE atau EE yang tidak diposkan ke area unduhan publik untuk CE atau area unduhan klien / terlindungi untuk EE. Itu akan membutuhkan Magento untuk membuat kebijakan yang konsisten bahwa SEMUA tambalan tersedia untuk SEMUA pelanggan, dan mengirimkannya ke tempat yang bisa kami tuju.

Jadi, saya tidak berpikir ada cara untuk mengotomatisasi 100% ini sampai terjadi perubahan di sisi Magento, sayangnya.


2
Dengan repositori github versi magento, sepele membiarkan git melakukan pekerjaannya. Tidak perlu hashing khusus. Cukup tambahkan jarak jauh, ambil jarak jauh dan git diff depot/master origin/master. Tantangannya adalah .gitignore. Pilihan lain, adalah untuk mengkloning versi ke direktori terpisah, lalu salin app/code/coredirektori situs di atasnya. git diff -wakan memberi tahu Anda.
Melvyn

Kami melakukannya dengan cara ini karena kami sering menguji ini dari jarak jauh pada server yang tidak memungkinkan kami untuk menginstal perangkat lunak dan mungkin tidak menginstal git. Dalam lingkungan di mana git hadir, Anda benar, Anda dapat menggunakan git diff.
Joshua S Warren

Ah ya, saya mengerti maksud Anda. Sebenarnya aku akan memikirkan bagaimana cara mendapatkan sesuatu seperti ini ke magerun.
Melvyn

4

Salah satu cara yang saya dekati ketika saya melakukan banyak upgrade dan mencoba mensistematisasikan prosesnya adalah dengan benar-benar melakukan patch secara langsung ke repositori kode inti yang Anda gunakan untuk berbeda.

Ini sebenarnya memiliki dua manfaat:

  1. Tidak ada lagi false positive yang muncul di diff Anda.

  2. Katakanlah Anda memiliki situs yang tidak memiliki tambalan tertentu. Anda mungkin mengatakan itu masalah karena itu akan muncul sebagai kode yang hilang di diff Anda meskipun secara teknis mereka tidak kehilangan apa-apa dibandingkan dengan unduhan baru yang belum ditonton. Tetapi pada kenyataannya, bahwa mereka kehilangan tambalan sebenarnya adalah masalah yang harus diselesaikan - jadi itu sempurna yang muncul di diff Anda untuk Anda perbaiki bersama dengan peningkatan.


4

Saya tidak berpikir bahwa memiliki Magento di repo proyek Anda pada awalnya adalah ide yang baik, jika Anda mengelola lebih dari 2-3 klien. Karena selalu lebih mudah untuk mengacaukan tambalan sistem yang diterapkan dengan peretasan inti.

Pilihan terbaik, menurut saya, adalah memiliki mirror repositori Magento komposer dengan tag versi, yang mengarah ke versi Magento tertentu dengan kemungkinan tambalan resmi yang diterapkan.

Juga akan lebih mudah untuk mempertahankan tambalan Anda sendiri ke file, seperti Mage_Core_Model_Config untuk situs web yang memuat banyak dan lainnya, dengan memperkenalkan angsuran mereka melalui komposer dengan nomor versi yang cocok dengan angsuran Magento Anda.

Jadi, dalam hal ini, pemutakhiran semua proyek pelanggan Anda ke kode Magento yang ditambal hanya akan menghasilkan benjolan versi file komposer Anda. Juga menjaga kode proyek terpisah dari inti, akan memaksa pengembang Anda untuk tidak meretas inti.

Adapun definisi tambalan dan peretasan, saya lebih suka menyebutnya seperti ini:

  1. Perubahan file inti asli dengan file tambalan resmi - ini adalah tambalan
  2. Perubahan pada file inti asli oleh tim Anda - ini adalah peretasan.
  3. Perubahan pada file inti lokal yang disalin untuk tujuan perbaikan bug - ini merupakan tambalan
  4. Perubahan pada file inti yang disalin lokal untuk memasok fungsionalitas baru - ini adalah peretasan

Jadi dengan memindahkan inti ke repo terpisah, Anda akan memastikan bahwa Anda hanya memiliki versi tambalan sesuai dengan item 1. Dan Anda dapat dengan mudah menginstal tambalan Anda sendiri di atas komposer ke kumpulan kode lokal, sehingga Anda memiliki segalanya sesuai dengan poin 3. Dalam kasus 2 dan 4 Anda dapat membuat hook komit git di repo proyek untuk melarang komit kode apa pun ke dir itu.


3

Saya melihat ke file tambalan yang diterapkan dalam /app/etc/folder itu dan bekerja mundur. Tetapi ketika saya belajar dari peningkatan, saya hanya dapat menghapus file pada versi yang memiliki file tambalan di dalamnya dan lain kali ditambal itu bersih.


2

Apa pun dari Magento, aku akan menelepon tambalan. Yang lainnya adalah retasan.


1
Setuju, tapi bagaimana cara membedakan mana yang setelah fakta.
Alan Storm

Saya mungkin akan melakukan perbandingan Anda membandingkan pada instalasi dasar dan kemudian membandingkan tambahan terhadap instalasi dengan setiap patch diterapkan secara terpisah (atau hanya hasil akhir dari semua patch yang diterapkan). Itu mungkin akan menjadi beberapa urutan besarnya lebih banyak pekerjaan, tapi itu satu-satunya cara saya bisa memikirkan.
Josh Pennington
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.