Bagaimana cara mengevaluasi ekstensi pihak ke-3?

Sementara Magento melakukan banyak hal 'out of the box', kami menemukan ada banyak fitur dan fasilitas yang diperlukan untuk toko klien yang membutuhkan ekstensi pihak ke-3.

Namun, mengingat sifat mediumnya, itu bisa menjadi proposisi yang berisiko untuk memperkenalkan kode 'asing' ke sistem yang rumit yang berurusan dengan transaksi komersial.

Apa yang Anda cari saat mengevaluasi ekstensi Magento? Apa 'bendera merah' yang Anda temui (babi kinerja, risiko keamanan, praktik buruk arsitektur)?

Berikut adalah beberapa pemikiran untuk mengevaluasi Modul Pihak Ketiga:

Dasar-dasar:

• Dukungan Versi Magento Terkini - Apakah mendukung Magento versi terbaru (termasuk yang sedang kami kembangkan)?

  Jika sebuah modul tidak mendukung rilis terbaru Magento, mungkin akan sulit untuk membuatnya bekerja tanpa menghabiskan waktu pengembangan yang berharga di atasnya.

• Dukungan - Apakah pengembang yang membuat modul mendukung produk?

  Salah satu tanda modul yang sehat adalah bahwa pengembang secara aktif mendukungnya. Jika mereka tidak mendukung itu adalah bendera merah, mengapa mereka tidak akan mendukung produk jika bagus?

  Selain itu, ketika modul didukung, kami biasanya dapat memperoleh info penting dari pengembang dengan email sederhana (misalnya, apakah modul ini menggunakan jQuery atau Prototype).

• Ulasan - Apa yang pengguna lain katakan? Bagaimana pengalaman mereka?

  Dengan membaca ulasan kita bisa mendapatkan gambaran yang lebih baik, apakah ada masalah instalasi? Apakah pengembang merespons secara tepat waktu dan bermanfaat? Apakah itu berfungsi seperti yang diiklankan?

• Pengembalian Dana - Apakah mereka akan mengembalikan uang Anda jika tidak berhasil seperti yang dimaksudkan?

  Berkali-kali kami ingin mencoba modul tersebut sehingga kami dapat mengujinya, jika berfungsi dan memenuhi spesifikasi kami dengan hebat! Tetapi jika tidak, kami ingin opsi mengembalikannya dan mendapatkan pengembalian uang untuk itu.

Menengah:

• Class Override - Apakah modul menimpa kelas inti?

  Secara umum, modul yang baik tidak boleh mengesampingkan kelas inti, melainkan harus menggunakan Pengamat.

  Salah satu alasannya, hal ini dapat membuat peningkatan Magento menjadi sulit. Selain itu, modul lain mungkin tergantung pada satu output dari fungsi yang diberikan, dan modul ini memberikan yang berbeda.

  Kadang-kadang ini tidak mungkin dilakukan, jika ini masalahnya, harus ada alasan yang sangat bagus mengapa ini menimpa kelas inti.

• Pembaruan tata letak - Apakah modul mengubah beberapa pengaturan tata letak saya?

  Beberapa modul mengubah pengaturan tata letak ke situs Anda (misalnya: halaman produk), pastikan itu tidak merusak tata letak Anda saat ini, dan jika melakukan apa yang diperlukan (baca: berapa banyak waktu yang diperlukan kami) untuk memperbaikinya .

• Perubahan template - Apakah modul menyertakan template yang mengubah desain saya saat ini?

  Apakah modul ini akan memperkenalkan template baru? Jika ya, apakah mereka akan merusak desain saya? Berapa lama waktu yang diperlukan untuk memiliki desain seperti yang kita inginkan?

• Ketergantungan - Apakah modul bergantung pada modul lain?

  Jika modul tergantung pada orang lain, kita perlu memastikan mereka ada di sana dan diinstal. Selain itu kita perlu bertanya pada diri sendiri, apakah kita ingin mematikan modul itu tergantung di masa depan?

Maju:

• Skrip Peningkatan SQL - Apakah modul memperbarui DB dengan cara tertentu?

  Setelah modul memperbarui basis data, kami perlu memastikan beberapa hal.

  Apakah itu memperbarui tabel inti? Jika ya, itu tidak baik, kami ingin database kami bersih dan siap untuk ditingkatkan.

  Apakah ia menyimpan informasi dengan cara yang masuk akal? Jika kita ingin mendapatkan data mentah dari database sendiri, apakah kita dapat memahaminya?

• Acara - Apakah modul mengamati atau mengirim acara?

  Jika modul mengirim atau mengamati acara, kami ingin tahu:

  Peristiwa apa yang ia amati / kirimkan? Apakah ini akan memengaruhi modul lain yang bekerja di sistem. Misalnya, jika salah satu modul kami mengubah nama produk kami yang dimuat menjadi huruf besar, dan modul ini menambahkan kata 'gratis' ke nama produk yang dimuat, bagaimana cara kerjanya? Akankah kata 'bebas' juga keluar dalam jumlah besar?

• Tinjauan Kode - Apakah modul menggunakan teknik pengkodean yang dapat diterima?

  Ini lebih berkaitan dengan teknik pengkodean PHP daripada Magento.

  Apakah kodenya menggunakan blok Coba / Tangkap?

  Apakah kode keluar dari input pengguna?

  Spesifikasi ini sangat tergantung pada tingkat keterampilan / persyaratan kami.

• Masalah potensial - Masalah potensial apa yang dapat muncul akibat pemasangan modul ini?

  Coba bayangkan lima masalah teratas yang bisa muncul jika kita menginstal modul ini, walaupun mengejutkan, itu benar-benar memberi wawasan tentang proyek secara keseluruhan.

Intinya:

Semua hal ini baik untuk dimiliki di dunia yang ideal, dalam skenario dunia nyata kita perlu melakukan hal ini yang disebut 'kompromi' :)

Selain itu, pedoman ini dimaksudkan sebagai bantuan bagi kami, bukan untuk menghalangi kami, sebagai hasilnya jika kami hanya memasang satu modul, katakanlah modul berbagi sosial, dan itu untuk klien yang membutuhkan pengaturan situs sederhana, ada tidak masuk akal dalam melakukan banyak penelitian.

Dengan kata lain: Ini semua tentang menjadi efisien dengan waktu kita, jika menggunakan pedoman (item dalam) ini membantu saya menghemat waktu dalam jangka panjang menggunakannya, jika tidak menjatuhkannya dan menghemat kewarasan Anda.

Beberapa bendera merah "praktik buruk" khusus Magento adalah:

• kode apa pun di app/code/local/Mage
• template yang ditimpa (file dalam app/designyang sudah ada di inti)
• menulis ulang kelas-kelas penting seperti catalog/product. Secara umum saya melihat dengan cermat setiap penulisan ulang, untuk melihat apakah itu bisa dihindari
• pelanggaran berat standar pengkodean Zend / Magento. Meskipun ini hanya tentang pemformatan kode, saya menyimpulkan bahwa para dev yang tidak peduli dengan standar kemungkinan besar akan ceroboh tentang hal-hal lain yang lebih penting juga.
• perubahan dalam tabel basis data inti
• teks kode dalam templat (tidak menggunakan mekanisme terjemahan) dan di tempat lain
• business logic in templates (aturan praktis: setiap kejadian Mage::getModeldalam direktori templates biasanya pertanda buruk)

Beberapa tanda bahaya terkait PHP (ini adalah daftar yang sangat selektif dan tidak lengkap):

• Pemberitahuan dan Peringatan apa pun dengan pelaporan kesalahan yang diaktifkan ( E_STRICT)
• penggunaan @operator
• tidak membersihkan data pengguna sebelum keluaran

Beberapa tanda bahaya terkait kinerja:

• permintaan basis data di dalam loop
• memuat seluruh koleksi hanya untuk menggunakan sebagian saja

Juga perhatikan Bau Kode umum , itu tidak perlu bendera merah tetapi membantu memperkirakan kualitas secara keseluruhan.

Langkah # 1 - Dapatkah klien Anda mampu mendukung ekstensi ini jika pengembang menjalankan AWOL?

Jika tidak, Anda tidak dapat menggunakan ekstensi.

Jika ya, lanjutkan ke evaluasi ekstensi.

Orang-orang baik di Inchoo memiliki artikel tentang menganalisis kode modul pihak ke-3. Artikel tersebut menyebutkan penulisan ulang kelas, pekerjaan cron, pembaruan tata letak, dan pengamat acara.

Saya telah menemukan kode pengamat peristiwa memiliki potensi untuk hit kinerja tertinggi. Carilah sumber daya yang intensif, kode pihak ketiga yang berjalan untuk acara yang sering dikirim. Acara seperti, controller_action_predispatch, atau pemuatan koleksi.

Saya menggunakan modul utilitas ini dari Prattski untuk mendapatkan gambaran bagus tentang penulisan ulang dan pengamat.

Memiliki templat dan aset kulit yang terletak di default / default (atau pro atau perusahaan) bukan basis / default cukup mengganggu.

Kode yang dikaburkan adalah sesuatu yang harus diwaspadai - mencari panggilan ke eval (), base64_decode (), dan sejenisnya. Ini sering digunakan untuk validasi lisensi, tetapi bisa berbahaya atau menakutkan - Saya telah melihat setidaknya satu komponen yang mengevaluasi kode arbiter dari umpan RSS.

Cari panggilan dl () - setidaknya satu komponen gateway pembayaran yang saya lihat mengharuskan menginstal ekstensi PHP untuk melakukan koneksinya!

Kamu benar.

Sayangnya tidak ada keajaiban: Anda harus mengujinya, memeriksa kode untuk melihat apakah itu dikembangkan dengan baik, memiliki dukungan yang baik untuk modul komersial berkat forum mereka atau kecepatan untuk menjawab pertanyaan Anda ...

Ada beberapa ulasan tentang Magento Connect dan popularitas ekstensi dapat membantu untuk mengetahui apakah itu berharga atau tidak tetapi jujur ​​Anda dapat menemukan modul yang sangat populer dengan banyak bug. Saya punya contoh yang bagus minggu lalu dengan modul MailChimp, terutama dilakukan dengan baik tetapi saya harus memperbaiki beberapa bug dan memberikannya kepada pengembang. Selalu ada risiko, Anda harus menguji.

WebShopApp memiliki ide untuk mendorong ke arah ini, saya bermaksud membawa platform untuk mendapatkan informasi yang baik tentang modul. Idenya adalah untuk mendorong Magento ke arah ini. Jadi kualitas modul adalah pertanyaan aktual.

Saran saya: sangat memperhatikan modul-modul yang menginstal / memutakhirkan skrip yang mengubah nilai dalam tabel inti karena tidak selalu mudah untuk mengembalikan perubahan semacam itu.

Tes # 1 yang bisa saya buat adalah menemukan eksploitasi nol hari dalam kode mereka (biasanya tidak terlalu sulit dengan ekstensi Magento), melaporkan hanya kerusakan yang dihasilkan dari eksploit tiruan kepada tim keamanan mereka (tidak memberikan indikasi yang bagian dari kode rentan), dan mulai stop-watch - karena inilah yang akan terjadi ketika situs Anda diretas. Ketika staf pendukung mereka meminta FTP global dan akses mysql, tolak dengan sopan yang menyatakan bahwa itu melanggar PCI-DSS dan menawarkan untuk membiarkan mereka memiliki akses hanya baca ke repositori kode sumber Anda.

Tes # 2 yang saya lakukan adalah untuk memanggil vendor dan menangkap mereka lengah. Tanyakan kepada mereka tes perilaku / unit apa yang mereka lakukan, sistem kontrol sumber apa yang mereka gunakan, versi PHP mana yang mereka uji, versi Magento mana yang diuji, server web mana yang diuji, apakah mereka menggunakan browser atau tidak -tumpukan untuk menguji komponen front-end, dll ... Jika vendor tidak tahu apa yang Anda bicarakan, bungkam atau ingin "meminta ahli untuk mengirimi Anda email kembali", jalankan seperti neraka karena kemungkinan besar mereka menggunakan nomor zip file untuk "kontrol versi" dan hanya memperbaiki bug 3 bulan setelah pelanggan mereka melaporkannya.

Berbicara tentang PCI-DSS, semua modifikasi sistem juga diharuskan memiliki strategi pengembalian. Dengan modul yang menambahkan kolom yang tidak dapat dibatalkan ke tabel inti, ini menjadi hampir mustahil sambil tetap mempertahankan strategi pengembalian yang akan lulus audit. Jalankan seperti neraka dari modul apa pun yang akan menyebabkan masalah (baca: Kesalahan SQL) saat dinonaktifkan.

PCI-DSS v3

6.4.5.4 Prosedur mundur.

Verifikasi bahwa prosedur mundur disiapkan untuk setiap perubahan sampel.

Untuk setiap perubahan, harus ada prosedur mundur yang didokumentasikan jika perubahan gagal atau berdampak buruk pada keamanan aplikasi atau sistem, untuk memungkinkan sistem dikembalikan ke keadaan semula.

Ini, di samping jawaban lainnya. IMO harus ada dinding malu untuk beberapa omong kosong berbahaya yang telah muncul di platform ini.