Saat Anda bersiap untuk mengupgrade aplikasi web Anda dari ASP.NET 1.1 ke ASP.NET 2.0, Anda akan menghadapi masalah cookie: semua cookie yang disimpan oleh klien di aplikasi ASP.NET 1.1 akan menjadi tidak valid.
Blog Park juga mengalami masalah seperti itu. Untuk Blog Park, artinya semua pengguna yang menggunakan cookie harus login lagi. Meskipun ini bukan masalah besar, namun akan membawa masalah bagi semua orang lebih merepotkan.
Untuk situs web yang sangat mementingkan kepuasan pengguna, upaya harus dilakukan untuk mengatasi masalah ini. Blog Park berharap dapat mengurangi dampak pemutakhiran sebanyak mungkin, jadi saya telah mempelajari masalah ini selama dua hari terakhir dan menemukan solusinya.
Penyebab masalahnya adalah: ketika program diupgrade dari ASP.NET 1.1 ke ASP.NET 2.0, ASP.NET 2.0 menggunakan algoritma dan kunci baru untuk mendekripsi cookie yang dikirim oleh klien, yang mengakibatkan Cookie tidak valid di ASP.NET 2.0. Di ASP.NET 1.1, algoritma 3DES digunakan untuk mengenkripsi konten cookie, sedangkan di ASP.NET 2.0, algoritma Advanced Encrypted Standards (AES) digunakan secara default untuk mendekripsi Anda dapat menggunakan pengaturan yang sesuai untuk Untuk mengubah algoritma enkripsi cookie di ASP.NET 2.0 menjadi 3DES, cukup tambahkan: <machineKey decryption="3DES"/> ke web.config. Namun setelah melakukan hal tersebut, permasalahan tetap ada, karena selain algoritma yang sama, diperlukan juga kunci yang sama untuk dekripsi. Jika tidak ada kunci yang ditentukan di machineKey, ASP.NET 2.0 akan menggunakan kunci yang dibuat secara acak secara default. Kunci acak ini dibuat oleh System.Web.HttpRuntime.SetAutogenKeys() dan disimpan di System.Web.HttpRuntime.s_autogenKeys nilai ini melalui refleksi. machineKey dari ASP.NET 1.1 diatur di machine.config, dan kunci acak juga digunakan secara default:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>.
Masalahnya terletak pada kunci acak yang berbeda. Jika Anda menentukan kunci dalam ASP.NET 1.1 asli, masalah ini tidak akan ada, namun hal ini umumnya dipertimbangkan saat menggunakan peternakan Web. Jadi biasanya kunci acak digunakan. ASP.NET akan menghasilkan kunci acak yang berbeda untuk aplikasi yang berbeda. Masalah kegagalan cookie klien ini akan terjadi dalam banyak situasi, seperti: menginstal ulang sistem, memindahkan aplikasi ASP.NET ke komputer lain, Aplikasi web dipindahkan ke direktori virtual yang berbeda. dan sebagainya.
Bagaimana cara mengatasi masalah ini?
Prinsipnya sangat sederhana, selama kita mengetahui nilai kunci yang dihasilkan secara acak di ASP.NET 1.1, lalu menentukannya di web.config aplikasi ASP.NET 2.0 Ada dua kunci di sini: satu adalah enkripsi Kunci decryptionKey, salah satunya adalah kunci perhitungan hash validationKey (untuk mencegah cookie dirusak di tengah jalan). Jika kita mengetahui kuncinya adalah: X dan Y, maka di web.config
Masalah ini dapat diatasi dengan melakukan pengaturan berikut:
<machineKey validationKey="X" decryptionKey="Y" decryption="3DES"/>
Masalahnya adalah bagaimana mendapatkan nilai kunci yang dihasilkan secara acak di ASP.NET 1.1. Kuncinya disimpan di LSA (Otoritas Keamanan Lokal Windows), tetapi saya tidak menemukan cara untuk mendapatkan kunci dari LSA.
Karena taman blog terutama memecahkan masalah cookie login, dan cookie ini dihasilkan di System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie), jadi saya mulai dari System.Web.Security dari ASP.NET 1.1 Mulai dengan kode sumber .FormsAuthentication, saya menemukan System.Web.Configuration.MachineKey. Setelah penelitian lebih lanjut tentang kode sumber MachineKey, saya menemukan dua kunci di MachineKeyConfig MachineKey, yang ada di dua anggota statis pribadi s_validationKey dan s_oDes ( Butuh banyak upaya untuk menemukan ini), nilai validationKey disimpan langsung di s_validationKey, dan decryptionKey disimpan di s_oDes.Key. Karena MachineKey adalah kelas internal dan MachineKeyConfig adalah tipe privat, kedua anggota tersebut adalah anggota statis privat dan tidak dapat diakses secara langsung. Saat ini, saatnya fungsi refleksi yang kuat di .NET mulai berperan. Kedua nilai ini diperoleh melalui refleksi. Perlu diperhatikan bahwa jenis kedua nilai ini adalah Byte[]. Melalui pengujian, ditemukan bahwa kunci yang dihasilkan dengan langsung mengubahnya menjadi string tidak valid. Anda perlu memanggil System.Web.Configuration.MachineKey.ByteArrayToHexString melalui refleksi (Byte[], Int32) yang dikonversi menjadi string.
Saya akhirnya menyelesaikan masalah ini malam ini, sangat bersemangat! Beberapa kali saya ingin menyerah di tengah-tengah, namun saya berpikir setelah program blog park diupgrade ke ASP.NET 2.0, masalah ini akan menimbulkan masalah bagi banyak orang. Walaupun saya hanya perlu login lagi, saya tetap merasakannya Saya perlu menyelesaikan masalah ini dan melakukan Bukankah pengembangan program dimaksudkan untuk memberikan kenyamanan sebanyak mungkin kepada pengguna?
Mengatasi masalah ini akan melakukan persiapan lebih lanjut untuk mengupgrade website Blog Park ke ASP.NET 2.0.
Sumber: programmer dudu-senang