Bagaimana seharusnya seseorang men-debug aplikasi web PHP dengan aman tanpa mengungkap rahasia kepada pesaing?

Baru-baru ini saya membuat program. Saya lupa menghapus 2 baris kode. Kesalahan itu menelan biaya $ 800 per hari setiap hari.

Saya pemrograman dengan PHP. Jika pengunjung menggunakan proxy, itu mengarahkan ulang di tempat lain. Menggunakan debugger tidak mungkin karena beberapa kode mengandung ioncube. Karena program hanya mengarahkan ke tempat lain, apa pun yang terjadi, sulit untuk melihat bagian mana dari kode yang dieksekusi.

Jadi saya menaruh banyak info debug di mana-mana. Saya pikir saya akan menghapusnya nanti.

Cara yang paling alami untuk debug tentu saja dengan memasukkan informasi debug ke dalam file. Masalahnya adalah saya sering menggunakan proxy. Jadi setelah saya mengubah program, saya sering harus mengunduh file teks dengan filezilla. Seringkali file teks tidak menunjukkan apa yang menurut saya harus ditampilkan. Akhirnya saya memutuskan untuk hanya menampilkan kesalahan di web.

Saya dianggap memiliki mode debugging. Namun, saya khawatir saya akan lupa menghapus info debugging.

Saya dianggap memiliki mode debugging jika pengguna melakukannya? Debuggingmode = 1 misalnya. Namun, saya paranoid bahwa pesaing saya bisa menebak kata kunci rahasia.

Saya menghapus sebagian besar info debug. Saya lupa menghapus satu dan yang itu hanya muncul jika pengguna menggunakan proxy dari negara yang tepat. Ternyata saya tidak punya proxy dari negara yang tepat dan tidak menyadarinya. Setelah program bekerja selama 24 jam, saya mengunggahnya ke domain utama saya.

Pesaing saya, menggunakan proxy, lihat kode debugging. Dia menyalin ide itu dan itulah mengapa saya kehilangan $ 800 per hari.

Dalam retrospeksi, saya benar-benar kesulitan melihat di mana saya salah. Saya sangat berhati-hati. Namun itu terjadi.

Bagaimana seharusnya seseorang men-debug aplikasi web PHP dengan aman tanpa mengungkap rahasia kepada pesaing?

Saya benar-benar kesulitan melihat di mana kesalahan saya

Kesalahan utama adalah Anda menemukan kembali kemudi. Alih-alih menggunakan mekanisme default untuk masuk, Anda membuat sendiri , yang menampilkan informasi di dalam halaman. Kerangka logging lebih suka menyimpan log dalam file log, membiarkan Anda untuk berkonsultasi log tersebut nanti dengan SSHing ke server.

Adapun bug, memproduksi kode bebas bug menyiratkan menggunakan teknik spesifik seperti bukti formal . Mengingat kemahalan mereka, teknik-teknik itu sesuai untuk aplikasi yang sangat penting seperti aplikasi yang mengendalikan lalu lintas pesawat atau pesawat ulang-alik, tetapi merupakan kerja keras untuk hampir setiap aplikasi bisnis.

■ Lihat Mereka menulis hal-hal yang benar di majalah Fast Company.
_{Artikel tersebut menjelaskan metodologi yang digunakan di NASA, serta biaya pembuatan perangkat lunak dengan cara ini.}

■ Lihat Bukti Mekanisasi (Mackenzie 2004).
_{Buku ini merangkum sejarah bukti perangkat lunak terotomatisasi, menjelaskan pro dan kontra bukti tersebut, serta alasan mengapa tidak umum digunakan oleh bisnis untuk menulis perangkat lunak yang andal.}

Ini dikatakan, ada banyak teknik yang digunakan untuk aplikasi bisnis untuk memastikan kualitas perangkat lunak. Itu termasuk tetapi tidak terbatas pada:

• Ulasan kode informal,
• Inspeksi kode formal,
• Pengujian,
• Pemeriksaan kode pribadi di meja,
• dll.

■ Lihat Kode lengkap (McConnell 2004), Pemrograman Produktivitas (Jones 1986a), Efisiensi Penghapusan Cacat Perangkat Lunak (Jones 1996), dan Apa yang Telah Kita Pelajari tentang Memerangi Cacat (Shull et al. 2002).

Juga, jangan lupa integrasi berkelanjutan dan pengiriman berkelanjutan. Ini membantu dalam secara otomatis mengembalikan aplikasi dalam produksi ke versi yang berfungsi ketika yang direvisi tampaknya memiliki masalah yang tidak terjawab selama ulasan kode dan pengujian unit, tetapi tertangkap setelah aplikasi dikerahkan.

■ Lihat Rahasia untuk Penempatan Berkelanjutan yang Aman (video).
_{Ini menjelaskan teknik apa yang telah disiapkan di Google untuk mencegah bug yang tidak dapat ditemukan sebelum penyebaran tetap terlalu lama dalam produksi. Ini juga menjelaskan pdiffdan bagaimana ia digunakan untuk menangkap bug, termasuk yang tidak terkait dengan lapisan presentasi.}

Anda tidak boleh men-debug dalam produksi.

Anda harus selalu memiliki lingkungan pengujian yang identik dengan lingkungan produksi dan debug di sana.

Ketika Anda perlu mengubah kode di lingkungan pengujian (seperti untuk menambahkan pernyataan debugging), Anda harus memastikan bahwa mereka tidak masuk ke produksi.

Pengaturan profesional biasanya terlihat seperti ini:

Production
   ^
Staging
   ^
Development

Contoh "Produksi", "Staging" dan "Pengembangan" aplikasi Anda harus seidentik mungkin sehingga bug yang terjadi dalam "Produksi" dapat direproduksi dalam "Staging" dan "Development", tetapi masih sepenuhnya terpisah dari satu sama lain sehingga apa pun yang terjadi di salah satu contoh tidak mempengaruhi yang lain.

Ketika Anda perlu menganalisis masalah, Anda melakukannya di "Pengembangan". Berantakan dengan pernyataan debug dan coba semua yang Anda inginkan. Ketika Anda menemukan solusi, Anda menerapkan perbaikan itu ke basis kode tidak berubah di "Staging" dan memverifikasi bahwa perbaikan itu berfungsi. Kemudian Anda mempromosikan perbaikan ke "Produksi".

Kontrol versi yang tepat dan sistem manajemen bangun dapat membantu Anda dengan itu.

Ini jarang dilakukan karena usahanya tidak bermanfaat. Bahkan jika Anda kehilangan $ 800 sehari, upaya membuktikan suatu program dengan cepat menjadi lebih besar dari itu, yang menyiratkan bahwa tidak ada alasan bisnis untuk melakukannya.

Jika menjadi tertentu adalah layak yang banyak (misalnya untuk Space Shuttle perangkat lunak atau kontrol rudal), maka Anda melakukan verifikasi formal, pengujian lengkap semua kemungkinan input, dll Memang, itu juga sangat sulit serta lambat dan mahal. Tetapi proyek-proyek dengan anggaran miliaran dolar juga cenderung memiliki orang-orang yang sangat cerdas. (Atau mungkin mereka hanya terbiasa - berita utama saat ini tampaknya bertentangan dengan aturan itu.)

Terkadang Anda perlu melakukan debug sistem langsung. Ya, Anda harus memiliki salinan pengembangan atau pementasan. Tetapi akan selalu ada perbedaan. Ini terutama benar jika kode ini berjalan di perangkat keras pelanggan. Atau berpotensi, banyak instalasi pelanggan yang berbeda.

Saya telah menggunakan teknik & debugging = 1 di masa lalu. Saya menduga sebagian besar pengembang PHP memiliki. Itu membalik saklar dalam kode yang memungkinkan debugging verbose lebih dalam aplikasi. Info itu biasanya akan dibuang ke file log - umumnya log apache (menggunakan error_log ()). Tapi, Anda juga bisa menampilkannya. Profiler kami, misalnya, akan mengumpulkan informasi dan kemudian menampilkan berbagai tolok ukur di bagian bawah halaman. Anda juga dapat menampilkan informasi debug sebagai komentar HTML, atau dalam elemen tersembunyi yang hanya dapat dilihat jika Anda melihat sumber halaman.

Jika situs Anda memiliki 'pengguna', Anda dapat membatasi debugging hanya untuk pengguna tertentu. Dengan cara ini jika seseorang mencoba mengaktifkan debugging, itu masih tidak berfungsi kecuali mereka masuk sebagai pengguna itu.

Sekarang, Anda menyebutkan bahwa Anda menggunakan FileZilla untuk terhubung ke server. Seorang pengembang benar-benar harus memiliki akses SSH ke server. Itu akan membuat proses debug jauh lebih mudah bagi Anda. Misalnya, jika Anda akan mengeluarkan pernyataan debugging Anda ke log kesalahan Apache, misalnya, Anda kemudian dapat dengan mudah mengambil file itu untuk alamat IP Anda, dan melihat informasi debugging yang dihasilkan oleh permintaan halaman terakhir Anda.

Semua orang sudah membahas kasus umum:

Validasi formal (/ Kode Terbukti): Tidak layak untuk program dunia nyata, meskipun ada 4000 baris OS kernal, yang secara resmi terbukti, Butuh banyak siswa CS CS Rusia selama berbulan-bulan (beri komentar jika ingat nama proyek ini)

Pengujian CI << Pengujian Otomatis << Pengujian : pastikan Anda menggunakan alat cakupan untuk memeriksa kasus pengujian Anda memiliki cakupan 100%.

Untuk kasus khusus Anda meninggalkan kode debug dalam produksi, saya memiliki 2 opsi, yang keduanya membutuhkan kode sumber untuk dikompilasi ulang sebagai bagian dari penyebaran ke lingkungan baru (Staging / Final Testing).

1. Hapus itu pada waktu kompilasi. Bungkus kode debug dalam struktur seperti C # dan C #ifdef DEBUGuntuk memeriksa target build, (Baik Debug atau Rilis) dan untuk secara otomatis menghapusnya pada waktu kompilasi.

2. Tandai pada waktu Deploy. Letakkan komentar di dekat kode yang tidak boleh dijalankan di lingkungan nyata. Misalnya //TODO: Remove This Before Deployment, Lalu ketika dimigrasikan (digunakan) ke Staging, sebelum mengkompilasi kode, jalankan melalui skrip sederhana yang memeriksa untuk memastikan tidak ada komentar Bendera (misalnya //TODO:) yang tersisa di kode sumber.

Saya menyarankan yang pertama untuk jika jangka panjang dan Anda akan menginginkannya lagi (Misalnya mode logging verbose), dan nanti jika itu adalah hack cepat saat Anda sedang debugging (misalnya berbagai printf yang tersebar melalui kode Anda)

Seperti yang orang lain katakan di depan saya, banyak tes (unit dan fungsional), jika mungkin otomatis dan dengan cakupan kode yang baik adalah kunci untuk memiliki sebagian besar perangkat lunak bebas bug.

Jika saya memahami deskripsi masalah Anda dengan cukup baik, informasi debug ditampilkan pada halaman yang dilayani oleh server Anda. Jika itu masalahnya, Anda harus mempertimbangkan untuk memasukkan informasi itu ke dalam log yang tepat di server Anda. Dengan cara itu tidak pernah ditampilkan kepada pengguna akhir, bahkan jika Anda menggunakan versi 'verbose' untuk produksi. Ini adalah sesuatu yang baik untuk melakukan apa pun proyek yang sedang Anda kerjakan kecuali Anda memiliki alasan yang sangat baik untuk melakukan sebaliknya.

Apa yang orang lain katakan tentang debugging dalam produksi adalah benar. Tapi bagaimanapun saya sudah melakukannya. Dan saya pikir ada cara yang lebih aman untuk melakukannya daripada milik Anda, meskipun tidak ada yang mudah.

Saya sendiri tidak membutuhkan keamanan yang tinggi, saya hanya tidak ingin pengguna melihat banyak omong kosong di layar mereka.

$debug = true;
$allowed_ips = array('192.168.0.220','173.46.89.255'); // limit to your own ip's. If your competitor knows them, though, he can spoof it! But if your stuff is not top secret, it's ok. 

if(!in_array($_SERVER['REMOTE_ADDR'],$allowed_ips) ) {
  $debug = false;
}

if($debug) {
  echo '<pre>' . print_r($some_variable) . '</pre>';
}

Sekarang pengguna tidak akan melihat debug Anda kecuali mereka benar-benar mau. Jika $ 800 / hari Anda bergantung pada merahasiakan informasi debug ini, maka jangan gunakan kode di atas . Tetapi jika informasinya tidak terlalu sensitif, hal di atas akan jauh lebih baik daripada bergantung pada variabel GET atau mengungkapkan rahasia Anda ke seluruh negara.

Atau, Anda dapat membuat debugkelas atau fungsi yang akan memeriksa apakah pencetakan diizinkan atau tidak berdasarkan kriteria Anda. Itu yang saya lakukan.

Sesuatu seperti ini:

class debug {
  public $on = false;
  public static function print($variable) {
    if($on) {
      echo '<pre>' . print_r($some_variable) . '</pre>';
    }
  }
}

debug::print($some_variable); // class checks if printing is allowed. If not, no printing occurs.

Untuk program saya yang akan menghasilkan $ 800 / hari (dalam pengembangan), saya menggunakan apache mod auth untuk meminta kata sandi untuk mengakses bagian mana pun dari situs ini, serta membatasi informasi debug ke IP tertentu. Pertanyaan Anda membuat saya berpikir saya harus mencari keamanan yang lebih baik.

Sebenarnya, saya akan memiliki dua validasi tambahan di sini. Salah satunya adalah &debug=1parameter dalam permintaan. Anda juga dapat menggunakan beberapa variabel sesi khusus atau pengaturan cookie yang hanya dapat Anda aktifkan melalui panggilan ke halaman "rahasia" (lebih disukai dengan otentikasi).

Validasi kedua akan ada di file konfigurasi, array dengan rentang IP dan hanya panggilan dari IP dalam array yang dapat memicu fungsi debugging. sesuatu seperti

Dalam konfigurasi:

$debugAllowedIPs = array('127.0.0.1', '192.168.0.1', /* add more IPs here */);

Memiliki metode berikut di suatu tempat di mana ia dapat diakses secara global:

function getClientIp() {
    if (!empty($_SERVER['HTTP_CLIENT_IP']))  return $_SERVER['HTTP_CLIENT_IP'];
    if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) return $_SERVER['HTTP_X_FORWARDED_FOR'];
    return $_SERVER['REMOTE_ADDR'];
}

Dan dalam panggilan kode Anda sesuatu seperti:

if (in_array(getClientIp(), $debugAllowedIPs)) { /* show debug info here */ }

Harap diingat bahwa kode dalam getClientIp()metode ini tidak aman karena nilainya $_SERVER['HTTP_X_FORWARDED_FOR']mudah dipalsukan, namun kode tersebut harus melayani tujuan menyampaikan maksud Anda.