Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
oleh Scott Mitchell
Saat menguji aplikasi ASP.NET secara lokal, kemungkinan Anda menggunakan ASP.NET Development Web Server. Namun, situs web produksi kemungkinan besar didukung IIS. Ada beberapa perbedaan antara bagaimana server web ini menangani permintaan, dan perbedaan ini dapat memiliki konsekuensi penting. Tutorial ini mengeksplorasi beberapa perbedaan jerman yang lebih.
Pengantar
Setiap kali pengguna mengunjungi aplikasi ASP.NET, browsernya mengirimkan permintaan ke situs web. Permintaan tersebut diambil oleh perangkat lunak server web, yang berkoordinasi dengan runtime ASP.NET untuk menghasilkan dan mengembalikan konten untuk sumber daya yang diminta. I nternet I nformation S ervices (IIS) adalah serangkaian layanan yang menyediakan fungsionalitas berbasis Internet umum untuk server Windows. IIS adalah server web yang paling umum digunakan untuk aplikasi ASP.NET di lingkungan produksi; kemungkinan besar perangkat lunak server web digunakan oleh penyedia host web Anda untuk melayani aplikasi ASP.NET Anda. IIS juga dapat digunakan sebagai perangkat lunak server web di lingkungan pengembangan, meskipun ini memerlukan penginstalan IIS dan mengonfigurasinya dengan benar.
ASP.NET Development Server adalah opsi server web alternatif untuk lingkungan pengembangan; ini dikirim dengan dan diintegrasikan ke dalam Visual Studio. Kecuali aplikasi web telah dikonfigurasi untuk menggunakan IIS, ASP.NET Development Server secara otomatis dimulai dan digunakan sebagai server web saat pertama kali Anda mengunjungi halaman web dari dalam Visual Studio. Aplikasi web demo yang kami buat kembali dalam tutorial Menentukan File Apa yang Perlu Disebarkan adalah aplikasi web berbasis sistem file yang tidak dikonfigurasi untuk menggunakan IIS. Oleh karena itu, saat mengunjungi salah satu situs web ini dari dalam Visual Studio, ASP.NET Development Server digunakan.
Dalam dunia yang sempurna, lingkungan pengembangan dan produksi akan identik. Namun, seperti yang kita bahas dalam tutorial sebelumnya tidak jarang lingkungan memiliki pengaturan konfigurasi yang berbeda. Menggunakan perangkat lunak server web yang berbeda di lingkungan menambahkan variabel lain yang harus dipertimbangkan saat menyebarkan aplikasi. Tutorial ini mencakup perbedaan utama antara IIS dan ASP.NET Development Server. Karena perbedaan ini ada skenario di mana kode yang berjalan sempurna di lingkungan pengembangan melemparkan pengecualian atau berperilaku berbeda ketika dijalankan dalam produksi.
Perbedaan Konteks Keamanan
Setiap kali perangkat lunak server web menangani permintaan masuk, perangkat lunak tersebut mengaitkan permintaan tersebut dengan konteks keamanan tertentu. Informasi konteks keamanan ini digunakan oleh sistem operasi untuk menentukan tindakan apa yang diizinkan oleh permintaan. Misalnya, halaman ASP.NET mungkin menyertakan kode yang mencatat beberapa pesan ke file di disk. Agar halaman ASP.NET ini dijalankan tanpa kesalahan, konteks keamanan harus memiliki izin tingkat sistem file yang sesuai, yaitu izin tulis pada file tersebut.
Server Pengembangan ASP.NET mengaitkan permintaan masuk dengan konteks keamanan pengguna yang saat ini masuk. Jika Anda masuk ke desktop sebagai administrator, maka halaman ASP.NET yang dilayani oleh ASP.NET Development Server akan memiliki hak akses yang sama dengan administrator. Namun, ASP.NET permintaan yang ditangani oleh IIS dikaitkan dengan akun komputer tertentu. Secara default, akun komputer Layanan Jaringan digunakan oleh IIS versi 6 dan 7, meskipun penyedia host web Anda mungkin telah mengonfigurasi akun unik untuk setiap pelanggan. Terlebih lagi, penyedia host web Anda kemungkinan telah memberikan izin terbatas ke akun komputer ini. Hasil bersihnya adalah Anda mungkin memiliki halaman web yang dijalankan tanpa kesalahan di lingkungan pengembangan, tetapi menghasilkan pengecualian terkait otorisasi saat dihosting di lingkungan produksi.
Untuk menampilkan jenis kesalahan ini dalam tindakan Saya telah membuat halaman di situs web Ulasan Buku yang membuat file di disk yang menyimpan tanggal dan waktu terbaru seseorang melihat Teach Yourself ASP.NET 3.5 dalam tinjauan 24 Jam . Untuk mengikuti, buka ~/Tech/TYASP35.aspx halaman dan tambahkan kode berikut ke penanganan Page_Load aktivitas:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim filePath As String = Server.MapPath("~/LastTYASP35Access.txt")
Dim contents As String = String.Format("Last accessed on {0} by {1}", _
DateTime.Now.ToString(), Request.UserHostAddress)
System.IO.File.WriteAllText(filePath, contents)
End Sub
Catatan
Metode ini File.WriteAllText membuat file baru jika tidak ada dan kemudian menulis konten yang ditentukan ke dalamnya. Jika file sudah ada, konten yang ada akan ditimpa.
Selanjutnya, kunjungi halaman ulasan buku Teach Yourself ASP.NET 3.5 in 24 Hours di lingkungan pengembangan menggunakan ASP.NET Development Server. Dengan asumsi bahwa Anda masuk ke komputer Anda dengan akun yang memiliki izin yang memadai untuk membuat dan memodifikasi file teks di direktori akar aplikasi web, tinjauan buku muncul sama seperti sebelumnya, tetapi setiap kali halaman dikunjungi tanggal dan waktu dan alamat IP pengguna disimpan dalam LastTYASP35Access.txt file. Arahkan browser Anda ke file ini; Anda akan melihat pesan yang mirip dengan pesan yang diperlihatkan dalam Gambar 1.
Gambar 1: File Teks Berisi Tanggal dan Waktu Terakhir Tinjauan Buku Dikunjungi (Klik untuk melihat gambar ukuran penuh)
Sebarkan aplikasi web ke produksi lalu kunjungi halaman ulasan buku Teach Yourself ASP.NET 3.5 yang dihosting di 24 Jam . Pada titik ini Anda akan melihat halaman ulasan buku seperti biasa atau pesan kesalahan yang ditunjukkan pada Gambar 2. Beberapa penyedia host web memberikan izin tulis ke akun komputer ASP.NET anonim, dalam hal ini halaman akan berfungsi tanpa kesalahan. Namun, jika penyedia host web Anda melarang akses tulis untuk akun anonim maka UnauthorizedAccessException pengecualian dimunculkan ketika TYASP35.aspx halaman mencoba menulis tanggal dan waktu saat ini ke LastTYASP35Access.txt file.
Gambar 2: Akun Komputer Default yang Digunakan oleh IIS Tidak Memiliki Izin untuk Menulis ke Sistem File (Klik untuk melihat gambar ukuran penuh)
Kabar baiknya adalah bahwa sebagian besar penyedia host web memiliki semacam alat izin yang memungkinkan Anda menentukan izin sistem file di situs web Anda. Berikan akses tulis akun ASP.NET anonim ke direktori akar lalu kunjungi kembali halaman ulasan buku. (Jika diperlukan, hubungi penyedia host web Anda untuk bantuan tentang cara memberikan izin tulis ke akun ASP.NET default.) Kali ini halaman harus dimuat tanpa kesalahan dan LastTYASP35Access.txt file harus berhasil dibuat.
Ambil di sini adalah bahwa karena server pengembangan ASP.NET beroperasi di bawah konteks keamanan yang berbeda dari IIS, ada kemungkinan bahwa halaman ASP.NET Anda yang membaca atau menulis ke sistem file, membaca dari atau menulis ke Log Peristiwa Windows, atau membaca atau menulis ke registri Windows akan berfungsi seperti yang diharapkan pada pengembangan tetapi menghasilkan pengecualian ketika pada produksi. Saat membangun aplikasi web yang akan disebarkan ke lingkungan hosting web bersama, jangan membaca atau menulis ke Log Peristiwa atau registri Windows. Perhatikan juga halaman ASP.NET yang membaca dari atau menulis ke sistem file karena Anda mungkin perlu memberikan hak istimewa baca dan tulis pada folder yang sesuai di lingkungan produksi.
Perbedaan Dalam Menyajikan Konten Statis
Perbedaan inti lainnya antara IIS dan ASP.NET Development Server adalah cara mereka menangani permintaan untuk konten statis. Setiap permintaan yang masuk ke ASP.NET Development Server, baik untuk halaman ASP.NET, gambar, atau file JavaScript, diproses oleh runtime ASP.NET. Secara default, IIS hanya memanggil runtime ASP.NET saat permintaan masuk untuk sumber daya ASP.NET, seperti halaman web ASP.NET, Layanan Web, dan sebagainya. Permintaan untuk konten statis - gambar, file CSS, file JavaScript, file PDF, file ZIP, dan seperangkatnya - diambil oleh IIS tanpa keterlibatan runtime ASP.NET. (Dimungkinkan untuk menginstruksikan IIS untuk bekerja dengan runtime ASP.NET saat menyajikan konten statis; lihat bagian "Melakukan Autentikasi Forms-Based dan Autentikasi URL pada File Statis dengan IIS 7" dalam tutorial ini untuk informasi lebih lanjut.)
Runtime ASP.NET melakukan sejumlah langkah untuk menghasilkan konten yang diminta, termasuk autentikasi (mengidentifikasi pemohon) dan otorisasi (menentukan apakah pemohon memiliki izin untuk melihat konten yang diminta). Bentuk autentikasi populer adalah autentikasi berbasis formulir, di mana pengguna diidentifikasi dengan memasukkan kredensial mereka - biasanya nama pengguna dan kata sandi - ke dalam kotak teks di halaman web. Setelah memvalidasi kredensial mereka, situs web menyimpan cookie tiket autentikasi di browser pengguna, yang dikirim dengan setiap permintaan berikutnya ke situs web dan adalah apa yang digunakan untuk mengautentikasi pengguna. Selain itu, dimungkinkan untuk menentukan aturan otorisasi URL yang menentukan apa yang dapat atau tidak dapat diakses oleh pengguna folder tertentu. Banyak situs web ASP.NET menggunakan autentikasi berbasis formulir dan otorisasi URL untuk mendukung akun pengguna dan untuk menentukan bagian situs yang hanya dapat diakses oleh pengguna atau pengguna terautentikasi yang termasuk dalam peran tertentu.
Catatan
Untuk pemeriksaan menyeluruh asp. Autentikasi berbasis formulir NET, otorisasi URL, dan fitur terkait akun pengguna lainnya, pastikan untuk melihat Tutorial Keamanan Situs Web saya.
Pertimbangkan situs web yang mendukung akun pengguna menggunakan otorisasi berbasis formulir dan memiliki folder yang, menggunakan otorisasi URL, dikonfigurasi untuk hanya mengizinkan pengguna yang diautentikasi. Bayangkan bahwa folder ini berisi halaman ASP.NET dan file PDF dan bahwa niatnya adalah bahwa hanya pengguna terautentikasi yang dapat melihat file PDF ini.
Apa yang terjadi jika pengunjung mencoba melihat salah satu file PDF ini dengan memasukkan URL langsung di bilah Alamat browsernya? Untuk mengetahuinya, mari kita buat folder baru di situs Ulasan Buku, tambahkan beberapa file PDF, dan konfigurasikan situs untuk menggunakan otorisasi URL untuk melarang pengguna anonim mengunjungi folder ini. Jika Anda mengunduh aplikasi demo, Anda akan melihat bahwa saya membuat folder bernama PrivateDocs dan menambahkan PDF dari Tutorial Keamanan Situs Web saya (seberapa pas!). Folder PrivateDocs juga berisi Web.config file yang menentukan aturan otorisasi URL untuk menolak pengguna anonim:
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Terakhir, saya mengonfigurasi aplikasi web untuk menggunakan autentikasi berbasis formulir dengan memperbarui file Web.config di direktori akar, menggantikan:
<authentication mode="Windows" />
Dengan:
<authentication mode="Forms" />
Dengan menggunakan ASP.NET Development Server, kunjungi situs dan masukkan URL langsung ke salah satu file PDF di bilah Alamat browser Anda. Jika Anda mengunduh situs web yang terkait dengan tutorial ini, URL akan terlihat seperti: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf
Memasukkan URL ini ke bilah Alamat menyebabkan browser mengirim permintaan ke server pengembangan ASP.NET untuk file tersebut. Server Pengembangan ASP.NET menyerahkan permintaan ke runtime ASP.NET untuk diproses. Karena kami belum masuk, dan karena Web.config di folder dikonfigurasi PrivateDocs untuk menolak akses anonim, runtime ASP.NET secara otomatis mengarahkan kami ke halaman masuk, Login.aspx (lihat Gambar 3). Saat mengalihkan pengguna ke halaman masuk, ASP.NET menyertakan ReturnUrl parameter querystring yang menunjukkan halaman yang coba ditampilkan pengguna. Setelah berhasil masuk, pengguna dapat dikembalikan ke halaman ini.
Gambar 3: Pengguna yang Tidak Sah Secara Otomatis Dialihkan ke Halaman Masuk (Klik untuk melihat gambar ukuran penuh)
Sekarang mari kita lihat bagaimana perilaku ini pada produksi. Sebarkan aplikasi Anda dan masukkan URL langsung ke salah satu PDF di PrivateDocs folder dalam produksi. Ini meminta browser Anda untuk mengirim permintaan IIS untuk file tersebut. Karena file statis diminta, IIS mengambil dan mengembalikan file tanpa memanggil runtime ASP.NET. Akibatnya, tidak ada pemeriksaan otorisasi URL yang dilakukan; konten PDF privat yang seharusnya dapat diakses oleh siapa saja yang tahu URL langsung ke file.
Gambar 4: Pengguna Anonim Dapat Mengunduh File PDF Privat Dengan Memasukkan URL Langsung ke File (Klik untuk melihat gambar ukuran penuh)
Melakukan Autentikasi Forms-Based dan Autentikasi URL pada File Statis dengan IIS 7
Ada beberapa teknik yang dapat Anda gunakan untuk melindungi konten statis dari pengguna yang tidak sah. IIS 7 memperkenalkan alur terintegrasi, yang menikahi alur kerja IIS dengan alur kerja runtime ASP.NET. Singkatnya, Anda dapat menginstruksikan IIS untuk memanggil modul autentikasi dan otorisasi runtime ASP.NET semua permintaan masuk (termasuk konten statis seperti file PDF). Hubungi penyedia host web Anda untuk mengetahui cara mengonfigurasi situs web Anda untuk menggunakan alur terintegrasi.
Setelah IIS dikonfigurasi untuk menggunakan alur terintegrasi, tambahkan markup berikut ke Web.config file di direktori akar:
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Markup ini menginstruksikan IIS 7 untuk menggunakan modul autentikasi dan otorisasi berbasis ASP.NET. Sebarkan ulang aplikasi Anda lalu kunjungi kembali file PDF. Kali ini ketika IIS menangani permintaan, IIS memberikan logika autentikasi dan otorisasi runtime ASP.NET kesempatan untuk memeriksa permintaan. Karena hanya pengguna terautentikasi yang berwenang untuk melihat konten di PrivateDocs folder, pengunjung anonim secara otomatis diarahkan ke halaman login (lihat kembali ke Gambar 3).
Catatan
Jika penyedia host web Anda masih menggunakan IIS 6 maka Anda tidak dapat menggunakan fitur alur terintegrasi. Salah satu solusinya adalah menempatkan dokumen privat Anda dalam folder yang melarang akses HTTP (seperti App_Data) lalu membuat halaman untuk melayani dokumen-dokumen ini. Halaman ini mungkin disebut GetPDF.aspx, dan diteruskan nama PDF melalui parameter querystring. Halaman pertama-tama GetPDF.aspx akan memverifikasi bahwa pengguna memiliki izin untuk melihat file dan, jika demikian, akan menggunakan Response.WriteFile(filePath) metode untuk mengirim konten file PDF yang diminta kembali ke klien yang meminta. Teknik ini juga akan berfungsi untuk IIS 7 jika Anda tidak ingin mengaktifkan alur terintegrasi.
Ringkasan
Aplikasi web di lingkungan produksi dihosting menggunakan perangkat lunak server web IIS Microsoft. Namun, di lingkungan pengembangan, aplikasi dapat dihosting menggunakan IIS atau server pengembangan ASP.NET. Idealnya, perangkat lunak server web yang sama harus digunakan di kedua lingkungan karena menggunakan perangkat lunak yang berbeda menambahkan variabel lain dalam campuran. Namun, kemudahan penggunaan ASP.NET Development Server menjadikannya pilihan yang menarik di lingkungan pengembangan. Kabar baiknya adalah bahwa hanya ada beberapa perbedaan mendasar antara IIS dan ASP.NET Development Server, dan jika Anda mengetahui perbedaan ini, Anda dapat mengambil langkah-langkah untuk membantu memastikan bahwa aplikasi berfungsi dan berfungsi dengan cara yang sama terlepas dari lingkungan.
Selamat Pemrograman!
Bacaan lebih lanjut
Untuk informasi selengkapnya tentang topik yang dibahas dalam tutorial ini, lihat sumber daya berikut: