Otorisasi Berbasis Pengguna (C#)

oleh Scott Mitchell

Catatan

Sejak artikel ini ditulis, penyedia Keanggotaan ASP.NET telah digantikan oleh identitas ASP.NET. Kami sangat menyarankan untuk memperbarui aplikasi untuk menggunakan platform identitas ASP.NET daripada penyedia Keanggotaan yang ditampilkan pada saat artikel ini ditulis. ASP.NET Identity memiliki sejumlah keunggulan dibandingkan sistem Keanggotaan ASP.NET, termasuk :

• Performa yang lebih baik
• Peningkatan ekstensibilitas dan uji coba
• Dukungan untuk OAuth, OpenID Connect, dan autentikasi dua faktor
• Dukungan Identitas berbasis klaim
• Interoperabilitas yang lebih baik dengan ASP.Net Core

Unduh Kode atau Unduh PDF

Dalam tutorial ini kita akan melihat membatasi akses ke halaman dan membatasi fungsionalitas tingkat halaman melalui berbagai teknik.

Pendahuluan

Sebagian besar aplikasi web yang menawarkan akun pengguna melakukannya sebagian untuk membatasi pengunjung tertentu mengakses halaman tertentu dalam situs. Di sebagian besar situs papan pesan online, misalnya, semua pengguna - anonim dan terautentikasi - dapat melihat posting papan pesan, tetapi hanya pengguna terautentikasi yang dapat mengunjungi halaman web untuk membuat posting baru. Dan mungkin ada halaman administratif yang hanya dapat diakses oleh pengguna tertentu (atau sekumpulan pengguna tertentu). Selain itu, fungsionalitas tingkat halaman dapat berbeda berdasarkan pengguna-demi-pengguna. Saat melihat daftar postingan, pengguna yang diautentikasi ditampilkan antarmuka untuk peringkat setiap postingan, sedangkan antarmuka ini tidak tersedia untuk pengunjung anonim.

ASP.NET memudahkan untuk menentukan aturan otorisasi berbasis pengguna. Hanya dengan sedikit markup di Web.config, halaman web tertentu atau seluruh direktori dapat dikunci sehingga hanya dapat diakses oleh subset pengguna tertentu. Fungsionalitas tingkat halaman dapat diaktifkan atau dinonaktifkan berdasarkan pengguna yang saat ini masuk melalui cara terprogram dan deklaratif.

Dalam tutorial ini kita akan melihat membatasi akses ke halaman dan membatasi fungsionalitas tingkat halaman melalui berbagai teknik. Mari kita mulai!

Lihat Alur Kerja Otorisasi URL

Seperti yang dibahas dalam tutorial Gambaran Umum Autentikasi Formulir, ketika runtime ASP.NET memproses permintaan sumber daya ASP.NET permintaan menimbulkan sejumlah peristiwa selama siklus hidupnya. Modul HTTP adalah kelas terkelola yang kodenya dijalankan sebagai respons terhadap peristiwa tertentu dalam siklus hidup permintaan. ASP.NET dikirim dengan sejumlah Modul HTTP yang melakukan tugas penting di belakang layar.

Salah satu Modul HTTP tersebut adalah FormsAuthenticationModule. Seperti yang dibahas dalam tutorial sebelumnya, fungsi utama adalah FormsAuthenticationModule menentukan identitas permintaan saat ini. Ini dilakukan dengan memeriksa tiket autentikasi formulir, yang terletak di cookie atau disematkan dalam URL. Identifikasi ini berlangsung selama peristiwa.AuthenticateRequest

Modul HTTP penting lainnya adalah UrlAuthorizationModule, yang dinaikkan sebagai respons terhadap AuthorizeRequest peristiwa (yang terjadi setelah AuthenticateRequest peristiwa). UrlAuthorizationModule Memeriksa markup konfigurasi untuk Web.config menentukan apakah identitas saat ini memiliki otoritas untuk mengunjungi halaman yang ditentukan. Proses ini disebut sebagai otorisasi URL.

Kita akan memeriksa sintaks untuk aturan otorisasi URL di Langkah 1, tetapi pertama-tama mari kita lihat apa yang UrlAuthorizationModule dilakukan tergantung pada apakah permintaan diotorisasi atau tidak. UrlAuthorizationModule Jika menentukan bahwa permintaan diotorisasi, permintaan tidak melakukan apa pun, dan permintaan berlanjut melalui siklus hidupnya. Namun, jika permintaan tidak diotorisasi, maka UrlAuthorizationModule membatalkan siklus hidup dan menginstruksikan Response objek untuk mengembalikan status TIDAK Sah HTTP 401. Saat menggunakan autentikasi formulir, status HTTP 401 ini tidak pernah dikembalikan ke klien karena jika FormsAuthenticationModule mendeteksi status HTTP 401 dimodifikasi menjadi HTTP 302 Alihkan ke halaman masuk.

Gambar 1 mengilustrasikan alur kerja alur ASP.NET, FormsAuthenticationModule, dan UrlAuthorizationModule kapan permintaan yang tidak sah tiba. Secara khusus, Gambar 1 menunjukkan permintaan oleh pengunjung anonim untuk ProtectedPage.aspx, yang merupakan halaman yang menolak akses ke pengguna anonim. Karena pengunjung bersifat anonim, UrlAuthorizationModule membatalkan permintaan dan mengembalikan status TIDAK Sah HTTP 401. Kemudian FormsAuthenticationModule mengonversi status 401 menjadi halaman Pengalihan 302 ke login. Setelah pengguna diautentikasi melalui halaman masuk, ia dialihkan ke ProtectedPage.aspx. Kali FormsAuthenticationModule ini mengidentifikasi pengguna berdasarkan tiket autentikasinya. Sekarang setelah pengunjung diautentikasi, UrlAuthorizationModule mengizinkan akses ke halaman.

Gambar 1: Alur Kerja Autentikasi Formulir dan Otorisasi URL (Klik untuk melihat gambar ukuran penuh)

Gambar 1 menggambarkan interaksi yang terjadi ketika pengunjung anonim mencoba mengakses sumber daya yang tidak tersedia untuk pengguna anonim. Dalam kasus seperti itu, pengunjung anonim dialihkan ke halaman login dengan halaman yang dia coba kunjungi yang ditentukan dalam querystring. Setelah pengguna berhasil masuk, dia akan secara otomatis dialihkan kembali ke sumber daya yang awalnya dia coba lihat.

Ketika permintaan yang tidak sah dibuat oleh pengguna anonim, alur kerja ini mudah dan mudah bagi pengunjung untuk memahami apa yang telah terjadi dan mengapa. Tetapi perlu diingat bahwa FormsAuthenticationModule akan mengalihkan pengguna yang tidak sah ke halaman masuk, bahkan jika permintaan dibuat oleh pengguna yang diautentikasi. Ini dapat mengakibatkan pengalaman pengguna yang membingungkan jika pengguna terautentikasi mencoba mengunjungi halaman yang tidak memiliki otoritas.

Bayangkan bahwa situs web kami memiliki aturan otorisasi URL yang dikonfigurasi singgah sehingga halaman OnlyTito.aspx ASP.NET hanya diakses ke Tito. Sekarang, bayangkan Bahwa Sam mengunjungi situs, masuk, dan kemudian mencoba untuk mengunjungi OnlyTito.aspx. UrlAuthorizationModule akan menghentikan siklus hidup permintaan dan mengembalikan status HTTP 401 Tidak Sah, yang FormsAuthenticationModule akan dideteksi dan kemudian mengalihkan Sam ke halaman masuk. Karena Sam telah masuk, meskipun, dia mungkin bertanya-tanya mengapa dia telah dikirim kembali ke halaman masuk. Dia mungkin beralasan bahwa kredensial masuknya hilang entah bagaimana, atau bahwa dia memasukkan kredensial yang tidak valid. Jika Sam memasukkan kembali kredensialnya dari halaman login, dia akan masuk (lagi) dan dialihkan ke OnlyTito.aspx. Akan UrlAuthorizationModule mendeteksi bahwa Sam tidak dapat mengunjungi halaman ini dan dia akan dikembalikan ke halaman masuk.

Gambar 2 menggambarkan alur kerja yang membingungkan ini.

Gambar 2: Alur Kerja Default Dapat Menyebabkan Siklus Membingungkan (Klik untuk melihat gambar ukuran penuh)

Alur kerja yang diilustrasikan dalam Gambar 2 dapat dengan cepat disaring bahkan pengunjung paling pamrih komputer. Kita akan melihat cara untuk mencegah siklus membingungkan ini di Langkah 2.

Catatan

ASP.NET menggunakan dua mekanisme untuk menentukan apakah pengguna saat ini dapat mengakses halaman web tertentu: Otorisasi URL dan otorisasi file. Otorisasi file diimplementasikan oleh FileAuthorizationModule, yang menentukan otoritas dengan berkonsultasi dengan ACL file yang diminta. Otorisasi file paling umum digunakan dengan autentikasi Windows karena ACL adalah izin yang berlaku untuk akun Windows. Saat menggunakan autentikasi formulir, semua permintaan tingkat sistem operasi dan sistem file dijalankan oleh akun Windows yang sama, terlepas dari pengguna yang mengunjungi situs. Karena seri tutorial ini berfokus pada autentikasi formulir, kita tidak akan membahas otorisasi file.

Cakupan Otorisasi URL

UrlAuthorizationModule adalah kode terkelola yang merupakan bagian dari runtime ASP.NET. Sebelum versi 7 server web Layanan Informasi Internet (IIS) Microsoft, ada hambatan yang berbeda antara alur HTTP IIS dan alur runtime ASP.NET. Singkatnya, di IIS 6 dan yang lebih lama, ASP. UrlAuthorizationModule NET hanya dijalankan ketika permintaan didelegasikan dari IIS ke runtime ASP.NET. Secara default, IIS memproses konten statis itu sendiri - seperti halaman HTML dan CSS, JavaScript, dan file gambar - dan hanya menyerahkan permintaan ke runtime ASP.NET saat halaman dengan ekstensi .aspx, , .asmxatau .ashx diminta.

Namun, IIS 7 memungkinkan IIS terintegrasi dan alur ASP.NET. Dengan beberapa pengaturan konfigurasi, Anda dapat menyiapkan IIS 7 untuk memanggil UrlAuthorizationModule untuk semua permintaan, yang berarti bahwa aturan otorisasi URL dapat didefinisikan untuk file dengan jenis apa pun. Selain itu, IIS 7 menyertakan mesin otorisasi URL-nya sendiri. Untuk informasi selengkapnya tentang integrasi ASP.NET dan fungsionalitas otorisasi URL asli IIS 7, lihat Memahami Otorisasi URL IIS7. Untuk melihat lebih mendalam integrasi ASP.NET dan IIS 7, ambil salinan buku Shahram Khosravi, Professional IIS 7 dan ASP.NET Integrated Programming (ISBN: 978-0470152539).

Singkatnya, dalam versi sebelum IIS 7, aturan otorisasi URL hanya diterapkan ke sumber daya yang ditangani oleh runtime ASP.NET. Tetapi dengan IIS 7 dimungkinkan untuk menggunakan fitur otorisasi URL asli IIS atau untuk mengintegrasikan ASP. UrlAuthorizationModule NET masuk ke dalam alur HTTP IIS, sehingga memperluas fungsionalitas ini ke semua permintaan.

Catatan

Ada beberapa perbedaan halang namun penting dalam bagaimana ASP. UrlAuthorizationModule Fitur otorisasi URL NET dan IIS 7 memproses aturan otorisasi. Tutorial ini tidak memeriksa fungsionalitas otorisasi URL IIS 7 atau perbedaan dalam cara mengurai aturan otorisasi dibandingkan UrlAuthorizationModuledengan . Untuk informasi selengkapnya tentang topik ini, lihat dokumentasi IIS 7 tentang MSDN atau pada www.iis.net.

Langkah 1: Menentukan Aturan Otorisasi URL diWeb.config

menentukan UrlAuthorizationModule apakah akan memberikan atau menolak akses ke sumber daya yang diminta untuk identitas tertentu berdasarkan aturan otorisasi URL yang ditentukan dalam konfigurasi aplikasi. Aturan otorisasi dieja dalam <authorization> elemen dalam bentuk elemen turunan <allow> dan <deny> . Setiap <allow> elemen anak dan <deny> dapat menentukan:

• Pengguna tertentu
• Daftar pengguna yang dibatasi koma
• Semua pengguna anonim, ditandai dengan tanda tanya (?)
• Semua pengguna, ditandai dengan tanda bintang (*)

Markup berikut mengilustrasikan cara menggunakan aturan otorisasi URL untuk memungkinkan pengguna Tito dan Scott dan menolak semua yang lain:

<authorization>
 <allow users="Tito, Scott" />
 <deny users="*" />
</authorization>

Elemen mendefinisikan <allow> apa yang diizinkan pengguna - Tito dan Scott - sementara <deny> elemen menginstruksikan bahwa semua pengguna ditolak.

Catatan

Elemen <allow> dan <deny> juga dapat menentukan aturan otorisasi untuk peran. Kami akan memeriksa otorisasi berbasis peran dalam tutorial mendatang.

Pengaturan berikut memberikan akses ke siapa pun selain Sam (termasuk pengunjung anonim):

<authorization>
 <deny users="Sam" />
</authorization>

Untuk mengizinkan hanya pengguna terautentikasi, gunakan konfigurasi berikut, yang menolak akses ke semua pengguna anonim:

<authorization>
 <deny users="?" />
</authorization>

Aturan otorisasi didefinisikan dalam <system.web> elemen di Web.config dan berlaku untuk semua sumber daya ASP.NET dalam aplikasi web. Seringkali, aplikasi memiliki aturan otorisasi yang berbeda untuk bagian yang berbeda. Misalnya, di situs eCommerce, semua pengunjung dapat melihat produk, melihat ulasan produk, mencari katalog, dan sebagainya. Namun, hanya pengguna terautentikasi yang dapat mencapai checkout atau halaman untuk mengelola riwayat pengiriman seseorang. Selain itu, mungkin ada bagian dari situs yang hanya dapat diakses oleh pengguna tertentu, seperti administrator situs.

ASP.NET memudahkan untuk menentukan aturan otorisasi yang berbeda untuk file dan folder yang berbeda di situs. Aturan otorisasi yang ditentukan dalam file folder Web.config akar berlaku untuk semua sumber daya ASP.NET di situs. Namun, pengaturan otorisasi default ini dapat diganti untuk folder tertentu dengan menambahkan Web.config dengan <authorization> bagian .

Mari kita perbarui situs web kami sehingga hanya pengguna yang diautentikasi yang dapat mengunjungi halaman ASP.NET di Membership folder. Untuk mencapai hal ini, kita perlu menambahkan Web.config file ke Membership folder dan mengatur pengaturan otorisasinya untuk menolak pengguna anonim. Membership Klik kanan folder di Penjelajah Solusi, pilih menu Tambahkan Item Baru dari menu konteks, dan tambahkan File Konfigurasi Web baru bernama Web.config.

Gambar 3: Tambahkan Web.config File ke Membership Folder (Klik untuk melihat gambar ukuran penuh)

Pada titik ini proyek Anda harus berisi dua Web.config file: satu di direktori akar dan satu di Membership folder.

Gambar 4: Aplikasi Anda Sekarang Harus Berisi Dua Web.config File (Klik untuk melihat gambar ukuran penuh)

Perbarui file konfigurasi di Membership folder sehingga melarang akses ke pengguna anonim.

<?xml version="1.0"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="?" />
 </authorization>
 </system.web>
</configuration>

Hanya itu saja!

Untuk menguji perubahan ini, kunjungi beranda di browser dan pastikan Anda keluar. Karena perilaku default aplikasi ASP.NET adalah mengizinkan semua pengunjung, dan karena kami tidak melakukan modifikasi otorisasi pada file direktori Web.config akar, kami dapat mengunjungi file di direktori akar sebagai pengunjung anonim.

Klik tautan Membuat Akun Pengguna yang ditemukan di kolom kiri. Ini akan membawa Anda ke ~/Membership/CreatingUserAccounts.aspx. Web.config Karena file dalam Membership folder menentukan aturan otorisasi untuk melarang akses anonim, UrlAuthorizationModule membatalkan permintaan dan mengembalikan status TIDAK Sah HTTP 401. Memodifikasi FormsAuthenticationModule ini ke status Pengalihan 302, mengirim kami ke halaman masuk. Perhatikan bahwa halaman yang kami coba akses (CreatingUserAccounts.aspx) diteruskan ke halaman masuk melalui ReturnUrl parameter querystring.

Gambar 5: Karena Aturan Otorisasi URL Melarang Akses Anonim, Kami Dialihkan ke Halaman Masuk (Klik untuk melihat gambar ukuran penuh)

Setelah berhasil masuk, kami diarahkan ke CreatingUserAccounts.aspx halaman. Kali UrlAuthorizationModule ini izin akses ke halaman karena kami tidak lagi anonim.

Menerapkan Aturan Otorisasi URL ke Lokasi Tertentu

Pengaturan otorisasi yang ditentukan di <system.web> bagian Web.config terapkan ke semua sumber daya ASP.NET di direktori tersebut dan subdirektorinya (sampai ditimpa oleh file lain Web.config ). Namun, dalam beberapa kasus, kita mungkin ingin semua sumber daya ASP.NET dalam direktori tertentu memiliki konfigurasi otorisasi tertentu kecuali untuk satu atau dua halaman tertentu. Ini dapat dicapai dengan menambahkan <location> elemen di Web.config, mengarahkannya ke file yang aturan otorisasinya berbeda, dan menentukan aturan otorisasi uniknya di dalamnya.

Untuk mengilustrasikan menggunakan <location> elemen untuk mengambil alih pengaturan konfigurasi untuk sumber daya tertentu, mari kita sesuaikan pengaturan otorisasi sehingga hanya Tito yang dapat mengunjungi CreatingUserAccounts.aspx. Untuk mencapai hal ini, tambahkan <location> elemen ke Membership file folder Web.config dan perbarui markupnya sehingga terlihat seperti berikut ini:

<?xml version="1.0"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="?" />
 </authorization>
 </system.web>

 <location path="CreatingUserAccounts.aspx">
 <system.web>
 <authorization>
 <allow users="Tito" />
 <deny users="*" />
 </authorization>
 </system.web>
 </location>
</configuration>

Elemen <authorization> dalam <system.web> menentukan aturan otorisasi URL default untuk sumber daya ASP.NET di Membership folder dan subfoldernya. Elemen ini <location> memungkinkan kita untuk mengambil alih aturan ini untuk sumber daya tertentu. Dalam markup <location> di atas, elemen mereferensikan CreatingUserAccounts.aspx halaman dan menentukan aturan otorisasinya seperti untuk mengizinkan Tito, tetapi menolak orang lain.

Untuk menguji perubahan otorisasi ini, mulailah dengan mengunjungi situs web sebagai pengguna anonim. Jika Anda mencoba mengunjungi halaman mana pun di Membership folder, seperti UserBasedAuthorization.aspx, UrlAuthorizationModule akan menolak permintaan dan Anda akan diarahkan ke halaman masuk. Setelah masuk sebagai, katakanlah, Scott, Anda dapat mengunjungi halaman mana pun di Membership folder kecuali untuk CreatingUserAccounts.aspx. Mencoba untuk mengunjungi CreatingUserAccounts.aspx yang masuk sebagai siapa pun tetapi Tito akan mengakibatkan upaya akses yang tidak sah, mengarahkan Anda kembali ke halaman masuk.

Catatan

Elemen <location> harus muncul di luar elemen konfigurasi <system.web> . Anda perlu menggunakan elemen terpisah <location> untuk setiap sumber daya yang pengaturan otorisasinya ingin Anda ambil alih.

Lihat BagaimanaUrlAuthorizationModuleMenggunakan Aturan Otorisasi untuk Memberikan atau Menolak Akses

menentukan UrlAuthorizationModule apakah akan mengotorisasi identitas tertentu untuk URL tertentu dengan menganalisis aturan otorisasi URL satu per satu, dimulai dari yang pertama dan bekerja ke bawah. Segera setelah kecocokan ditemukan, pengguna diberikan atau ditolak aksesnya, tergantung pada apakah kecocokan ditemukan dalam <allow> elemen atau <deny> . Jika tidak ada kecocokan yang ditemukan, pengguna akan diberikan akses. Akibatnya, jika Anda ingin membatasi akses, sangat penting bagi Anda untuk menggunakan <deny> elemen sebagai elemen terakhir dalam konfigurasi otorisasi URL. Jika Anda menghilangkan<deny>elemen, semua pengguna akan diberikan akses.

Untuk lebih memahami proses yang UrlAuthorizationModule digunakan oleh untuk menentukan otoritas, pertimbangkan contoh aturan otorisasi URL yang kita lihat sebelumnya dalam langkah ini. Aturan pertama adalah <allow> elemen yang memungkinkan akses ke Tito dan Scott. Aturan kedua adalah <deny> elemen yang menolak akses ke semua orang. Jika pengguna anonim mengunjungi, mulailah UrlAuthorizationModule dengan bertanya, Apakah anonim Scott atau Tito? Jawabannya, jelas, adalah Tidak, sehingga berlanjut ke aturan kedua. Apakah anonim dalam set semua orang? Karena jawabannya di sini adalah Ya, <deny> aturan diberlakukan dan pengunjung dialihkan ke halaman masuk. Demikian pula, jika Jisun berkunjung, UrlAuthorizationModule dimulai dengan bertanya, Apakah Jisun baik Scott atau Tito? Karena dia tidak, UrlAuthorizationModule berlanjut ke pertanyaan kedua, Apakah Jisun di set semua orang? Dia juga ditolak aksesnya. Akhirnya, jika Tito berkunjung, pertanyaan pertama yang diajukan oleh UrlAuthorizationModule adalah jawaban yang afirmatif, sehingga Tito diberikan akses.

UrlAuthorizationModule Karena proses aturan otorisasi dari atas ke bawah, berhenti pada kecocokan apa pun, penting untuk memiliki aturan yang lebih spesifik sebelum aturan yang kurang spesifik. Artinya, untuk menentukan aturan otorisasi yang melarang Jisun dan pengguna anonim, tetapi mengizinkan semua pengguna terautentikasi lainnya, Anda akan mulai dengan aturan yang paling spesifik - yang memengaruhi Jisun - dan kemudian melanjutkan ke aturan yang kurang spesifik - yang memungkinkan semua pengguna terautentikasi lainnya, tetapi menolak semua pengguna anonim. Aturan otorisasi URL berikut menerapkan kebijakan ini dengan terlebih dahulu menolak Jisun, lalu menolak pengguna anonim apa pun. Setiap pengguna terautentikasi selain Jisun akan diberikan akses karena tidak satu pun dari pernyataan ini <deny> yang akan cocok.

<authorization>
 <deny users="Jisun" />
 <deny users="?" />
</authorization>

Langkah 2: Memperbaiki Alur Kerja untuk Pengguna yang Tidak Sah dan Terautentikasi

Seperti yang kita bahas sebelumnya dalam tutorial ini di bagian A Look at the URL Authorization Workflow, kapan saja permintaan yang tidak sah bertranspires, UrlAuthorizationModule membatalkan permintaan dan mengembalikan status HTTP 401 Tidak Sah. Status 401 ini dimodifikasi oleh FormsAuthenticationModule menjadi status Pengalihan 302 yang mengirim pengguna ke halaman masuk. Alur kerja ini terjadi pada permintaan yang tidak sah, bahkan jika pengguna diautentikasi.

Mengembalikan pengguna yang diautentikasi ke halaman masuk kemungkinan akan membingungkan mereka karena mereka telah masuk ke sistem. Dengan sedikit pekerjaan, kami dapat meningkatkan alur kerja ini dengan mengalihkan pengguna terautentikasi yang membuat permintaan tidak sah ke halaman yang menjelaskan bahwa mereka telah mencoba mengakses halaman terbatas.

Mulailah dengan membuat halaman ASP.NET baru di folder akar aplikasi web bernama UnauthorizedAccess.aspx; jangan lupa untuk mengaitkan halaman ini dengan Site.master halaman master. Setelah membuat halaman ini, hapus kontrol Konten yang mereferensikan LoginContent ContentPlaceHolder sehingga konten default halaman master akan ditampilkan. Selanjutnya, tambahkan pesan yang menjelaskan situasinya, yaitu bahwa pengguna mencoba mengakses sumber daya yang dilindungi. Setelah menambahkan pesan seperti itu UnauthorizedAccess.aspx , markup deklaratif halaman akan terlihat mirip dengan yang berikut ini:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
CodeFile="UnauthorizedAccess.aspx.cs" Inherits="UnauthorizedAccess"
Title="Untitled Page" %>

<asp:Content ID="Content1" ContentPlaceHolderID="MainContent"
Runat="Server">
 <h2>Unauthorized Access</h2>
 <p>
 You have attempted to access a page that you are not authorized to view.
 </p>
 <p>
 If you have any questions, please contact the site administrator.
 </p>
</asp:Content>

Kita sekarang perlu mengubah alur kerja sehingga jika permintaan yang tidak sah dilakukan oleh pengguna terautentikasi, mereka dikirim ke UnauthorizedAccess.aspx halaman alih-alih halaman masuk. Logika yang mengalihkan permintaan yang tidak sah ke halaman masuk dikuburkan dalam metode FormsAuthenticationModule privat kelas, sehingga kami tidak dapat menyesuaikan perilaku ini. Namun, apa yang dapat kita lakukan adalah menambahkan logika kita sendiri ke halaman login yang mengalihkan pengguna ke UnauthorizedAccess.aspx, jika diperlukan.

FormsAuthenticationModule Ketika mengalihkan pengunjung yang tidak sah ke halaman login, ia menambahkan URL yang diminta dan tidak sah ke querystring dengan nama ReturnUrl. Misalnya, jika pengguna yang tidak sah mencoba mengunjungi OnlyTito.aspx, akan FormsAuthenticationModule mengalihkannya ke Login.aspx?ReturnUrl=OnlyTito.aspx. Oleh karena itu, jika halaman masuk dicapai oleh pengguna terautentikasi dengan querystring yang menyertakan ReturnUrl parameter , maka kita tahu bahwa pengguna yang tidak diautentikasi ini hanya mencoba mengunjungi halaman yang tidak diizinkan untuk dilihatnya. Dalam kasus seperti itu, kami ingin mengalihkannya ke UnauthorizedAccess.aspx.

Untuk mencapai hal ini, tambahkan kode berikut ke penanganan aktivitas halaman Page_Load masuk:

protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        if (Request.IsAuthenticated && !string.IsNullOrEmpty(Request.QueryString["ReturnUrl"]))
        // This is an unauthorized, authenticated request...
        Response.Redirect("~/UnauthorizedAccess.aspx");
    }
}

Kode di atas mengalihkan pengguna yang diautentikasi dan tidak sah ke UnauthorizedAccess.aspx halaman. Untuk melihat logika ini beraksi, kunjungi situs sebagai pengunjung anonim dan klik tautan Buat Akun Pengguna di kolom kiri. Ini akan membawa Anda ke ~/Membership/CreatingUserAccounts.aspx halaman, yang pada Langkah 1 kami konfigurasikan untuk hanya mengizinkan akses ke Tito. Karena pengguna anonim dilarang, FormsAuthenticationModule mengalihkan kami kembali ke halaman masuk.

Pada titik ini kita anonim, jadi Request.IsAuthenticated kembali false dan kita tidak diarahkan ke UnauthorizedAccess.aspx. Sebagai gantinya, halaman masuk ditampilkan. Masuk sebagai pengguna selain Tito, seperti Bruce. Setelah memasukkan kredensial yang sesuai, halaman masuk mengalihkan kami kembali ke ~/Membership/CreatingUserAccounts.aspx. Namun, karena halaman ini hanya dapat diakses oleh Tito, kami tidak berwenang untuk melihatnya dan segera dikembalikan ke halaman masuk. Namun kali ini, Request.IsAuthenticated mengembalikan (dan ReturnUrl parameter querystring ada), jadi kita diarahkan ke UnauthorizedAccess.aspx true halaman.

Gambar 6: Diautentikasi, Pengguna Tidak Sah dialihkan ke UnauthorizedAccess.aspx (Klik untuk melihat gambar ukuran penuh)

Alur kerja yang disesuaikan ini menyajikan pengalaman pengguna yang lebih masuk akal dan mudah dengan menyingkat sirkuit siklus yang digambarkan dalam Gambar 2.

Langkah 3: Membatasi Fungsionalitas Berdasarkan Pengguna yang Saat Ini Masuk

Otorisasi URL memudahkan untuk menentukan aturan otorisasi kasar. Seperti yang kita lihat di Langkah 1, dengan otorisasi URL, kita dapat dengan tepat menyatakan identitas apa yang diizinkan dan mana yang ditolak untuk melihat halaman tertentu atau semua halaman dalam folder. Namun, dalam skenario tertentu, kami mungkin ingin mengizinkan semua pengguna mengunjungi halaman, tetapi membatasi fungsionalitas halaman berdasarkan pengguna yang mengunjunginya.

Pertimbangkan kasus situs web eCommerce yang memungkinkan pengunjung terautentikasi untuk meninjau produk mereka. Ketika pengguna anonim mengunjungi halaman produk, mereka hanya akan melihat informasi produk dan tidak akan diberi kesempatan untuk meninggalkan ulasan. Namun, pengguna terautentikasi yang mengunjungi halaman yang sama akan melihat antarmuka peninjauan. Jika pengguna yang diautentikasi belum meninjau produk ini, antarmuka akan memungkinkan mereka untuk mengirimkan ulasan; jika tidak, itu akan menunjukkan kepada mereka tinjauan yang dikirimkan sebelumnya. Untuk mengambil skenario ini selangkah lebih jauh, halaman produk mungkin menampilkan informasi tambahan dan menawarkan fitur yang diperluas untuk pengguna yang bekerja untuk perusahaan eCommerce. Misalnya, halaman produk mungkin mencantumkan inventori dalam stok dan menyertakan opsi untuk mengedit harga dan deskripsi produk saat dikunjungi oleh karyawan.

Aturan otorisasi biji-bijian halus tersebut dapat diimplementasikan baik secara deklaratif atau terprogram (atau melalui beberapa kombinasi keduanya). Di bagian berikutnya kita akan melihat cara menerapkan otorisasi biji-bijian halus melalui kontrol LoginView. Setelah itu, kita akan mengeksplorasi teknik terprogram. Namun, sebelum kita dapat melihat penerapan aturan otorisasi biji-bijian halus, kita harus terlebih dahulu membuat halaman yang fungsionalitasnya tergantung pada pengguna yang mengunjunginya.

Mari kita buat halaman yang mencantumkan file di direktori tertentu dalam GridView. Bersama dengan mencantumkan nama, ukuran, dan informasi lainnya setiap file, GridView akan menyertakan dua kolom LinkButtons: satu berjudul Tampilan dan satu berjudul Hapus. Jika Tampilan LinkButton diklik, konten file yang dipilih akan ditampilkan; jika Hapus LinkButton diklik, file akan dihapus. Mari kita awalnya membuat halaman ini sehingga fungsionalitas tampilan dan penghapusannya tersedia untuk semua pengguna. Di bagian Menggunakan Kontrol LoginView dan Fungsionalitas Pembatasan Terprogram, kita akan melihat cara mengaktifkan atau menonaktifkan fitur-fitur ini berdasarkan pengguna yang mengunjungi halaman.

Catatan

Halaman ASP.NET yang akan kita buat menggunakan kontrol GridView untuk menampilkan daftar file. Karena seri tutorial ini berfokus pada autentikasi formulir, otorisasi, akun pengguna, dan peran, saya tidak ingin menghabiskan terlalu banyak waktu untuk membahas pekerjaan dalam kontrol GridView. Meskipun tutorial ini memberikan instruksi langkah demi langkah khusus untuk menyiapkan halaman ini, tutorial ini tidak mempelajari detail mengapa pilihan tertentu dibuat, atau efek apa yang dimiliki properti tertentu pada output yang dirender. Untuk pemeriksaan menyeluruh kontrol GridView, lihat seri tutorial Bekerja dengan Data di ASP.NET 2.0 saya.

Mulailah dengan membuka UserBasedAuthorization.aspx file di Membership folder dan menambahkan kontrol GridView ke halaman bernama FilesGrid. Dari Tag Cerdas GridView, klik tautan Edit Kolom untuk meluncurkan kotak dialog Bidang. Dari sini, hapus centang pada kotak centang Buat bidang secara otomatis di sudut kiri bawah. Selanjutnya, tambahkan tombol Pilih, tombol Hapus, dan dua BoundFields dari sudut kiri atas (tombol Pilih dan Hapus dapat ditemukan di bawah jenis CommandField). Atur properti tombol SelectText Pilih ke Tampilan dan properti dan DataField BoundField HeaderText pertama ke Nama. Atur properti BoundField HeaderText kedua ke Ukuran dalam Byte, propertinya DataField ke Panjang, propertinya DataFormatString ke {0:N0} dan propertinya HtmlEncode ke False.

Setelah mengonfigurasi kolom GridView, klik OK untuk menutup kotak dialog Bidang. Dari jendela Properti, atur properti GridView DataKeyNames ke FullName. Pada titik ini markup deklaratif GridView akan terlihat seperti berikut ini:

<asp:GridView ID="FilesGrid" DataKeyNames="FullName" runat="server" AutoGenerateColumns="False">
 <Columns>
 <asp:CommandField SelectText="View" ShowSelectButton="True"/>
 <asp:CommandField ShowDeleteButton="True" />
 <asp:BoundField DataField="Name" HeaderText="Name" />
 <asp:BoundField DataField="Length" DataFormatString="{0:N0}"
 HeaderText="Size in Bytes" HtmlEncode="False" />
 </Columns>
</asp:GridView>

Dengan markup GridView yang dibuat, kami siap untuk menulis kode yang akan mengambil file di direktori tertentu dan mengikatnya ke GridView. Tambahkan kode berikut ke penanganan aktivitas halaman Page_Load :

protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        string appPath = Request.PhysicalApplicationPath;
        DirectoryInfo dirInfo = new DirectoryInfo(appPath);

        FileInfo[] files = dirInfo.GetFiles();

        FilesGrid.DataSource = files;
        FilesGrid.DataBind();
    }
}

Kode di atas menggunakan DirectoryInfo kelas untuk mendapatkan daftar file di folder akar aplikasi. Metode mengembalikan semua file dalam direktori sebagai array FileInfo objek, yang kemudian terikat ke GridView.GetFiles() Objek FileInfo memiliki berbagai properti, seperti Name, , Lengthdan IsReadOnly, antara lain. Seperti yang Anda lihat dari markup deklaratifnya, GridView hanya Name menampilkan properti dan Length .

Catatan

Kelas DirectoryInfo dan FileInfo ditemukan di System.IO namespace layanan. Oleh karena itu, Anda harus mengawali nama kelas ini dengan nama namespace layanan mereka atau memiliki namespace yang diimpor ke dalam file kelas (melalui using System.IO).

Luangkan waktu sejenak untuk mengunjungi halaman ini melalui browser. Ini akan menampilkan daftar file yang berada di direktori akar aplikasi. Mengklik salah satu Tampilan atau Hapus LinkButtons akan menyebabkan postback, tetapi tidak ada tindakan yang akan terjadi karena kami belum membuat penanganan aktivitas yang diperlukan.

Gambar 7: GridView Mencantumkan File di Direktori Akar Aplikasi Web (Klik untuk melihat gambar ukuran penuh)

Kami memerlukan sarana untuk menampilkan konten file yang dipilih. Kembali ke Visual Studio dan tambahkan TextBox bernama FileContents di atas GridView. Atur propertinya TextMode ke MultiLine dan propertinya Columns Rows masing-masing menjadi 95% dan 10.

<asp:TextBox ID="FileContents" runat="server" Rows="10"
TextMode="MultiLine" Width="95%"></asp:TextBox>

Selanjutnya, buat penanganan aktivitas untuk peristiwa GridView SelectedIndexChanged dan tambahkan kode berikut:

protected void FilesGrid_SelectedIndexChanged(object sender, EventArgs e)
{
    // Open the file and display it
    string fullFileName = FilesGrid.SelectedValue.ToString();
    string contents = File.ReadAllText(fullFileName);
    FileContents.Text = contents;
}

Kode ini menggunakan properti GridView SelectedValue untuk menentukan nama file lengkap file yang dipilih. Secara internal, DataKeys koleksi dirujuk untuk mendapatkan SelectedValue, sehingga sangat penting bahwa Anda mengatur properti GridView DataKeyNames ke Nama, seperti yang dijelaskan sebelumnya dalam langkah ini. Kelas File digunakan untuk membaca konten file yang dipilih ke dalam string, yang kemudian ditetapkan ke FileContents properti TextBoxText, sehingga menampilkan konten file yang dipilih di halaman.

Gambar 8: Konten File yang Dipilih Ditampilkan di Kotak Teks (Klik untuk melihat gambar ukuran penuh)

Catatan

Jika Anda melihat konten file yang berisi markup HTML, lalu mencoba menampilkan atau menghapus file, Anda akan menerima kesalahan HttpRequestValidationException . Ini terjadi karena pada postback konten TextBox dikirim kembali ke server web. Secara default, ASP.NET menimbulkan kesalahan setiap kali konten postback yang HttpRequestValidationException berpotensi berbahaya, seperti markup HTML, terdeteksi. Untuk menonaktifkan kesalahan ini agar tidak terjadi, nonaktifkan validasi permintaan untuk halaman dengan menambahkan ke arahan ValidateRequest="false" @Page . Untuk informasi selengkapnya tentang manfaat validasi permintaan serta tindakan pencegahan apa yang harus Anda ambil saat menonaktifkannya, baca Validasi Permintaan - Mencegah Serangan Skrip.

Terakhir, tambahkan penanganan aktivitas dengan kode berikut untuk peristiwa GridView:RowDeleting

protected void FilesGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
    string fullFileName = FilesGrid.DataKeys[e.RowIndex].Value.ToString();
    FileContents.Text = string.Format("You have opted to delete {0}.", fullFileName);

    // To actually delete the file, uncomment the following line
    // File.Delete(fullFileName);
}

Kode hanya menampilkan nama lengkap file untuk dihapus di FileContents TextBox tanpa benar-benar menghapus file.

Gambar 9: Mengklik tombol Hapus Tidak Benar-benar Menghapus File (Klik untuk melihat gambar ukuran penuh)

Di Langkah 1 kami mengonfigurasi aturan otorisasi URL untuk melarang pengguna anonim melihat halaman di Membership folder. Untuk lebih baik menunjukkan autentikasi biji-bijian halus, mari kita izinkan pengguna anonim untuk mengunjungi UserBasedAuthorization.aspx halaman, tetapi dengan fungsionalitas terbatas. Untuk membuka halaman ini agar dapat diakses oleh semua pengguna, tambahkan elemen berikut <location> ke Web.config file di Membership folder :

<location path="UserBasedAuthorization.aspx">
 <system.web>
 <authorization>
 <allow users="*" />
 </authorization>
 </system.web>
</location>

Setelah menambahkan elemen ini <location> , uji aturan otorisasi URL baru dengan keluar dari situs. Sebagai pengguna anonim, Anda harus diizinkan untuk mengunjungi halaman.UserBasedAuthorization.aspx

Saat ini, setiap pengguna yang diautentikasi atau anonim dapat mengunjungi UserBasedAuthorization.aspx halaman dan melihat atau menghapus file. Mari kita buat agar hanya pengguna yang diautentikasi yang dapat melihat konten file dan hanya Tito yang dapat menghapus file. Aturan otorisasi biji-bijian halus tersebut dapat diterapkan secara deklaratif, terprogram, atau melalui kombinasi kedua metode. Mari kita gunakan pendekatan deklaratif untuk membatasi siapa yang dapat melihat konten file; kita akan menggunakan pendekatan terprogram untuk membatasi siapa yang dapat menghapus file.

Menggunakan Kontrol LoginView

Seperti yang telah kita lihat di tutorial sebelumnya, kontrol LoginView berguna untuk menampilkan antarmuka yang berbeda untuk pengguna yang diautentikasi dan anonim, dan menawarkan cara mudah untuk menyembunyikan fungsionalitas yang tidak dapat diakses oleh pengguna anonim. Karena pengguna anonim tidak dapat melihat atau menghapus file, kita hanya perlu menampilkan FileContents TextBox saat halaman dikunjungi oleh pengguna yang diautentikasi. Untuk mencapai hal ini, tambahkan kontrol LoginView ke halaman, beri nama LoginViewForFileContentsTextBox, dan pindahkan FileContents markup deklaratif TextBox ke kontrol LoggedInTemplateLoginView .

<asp:LoginView ID=" LoginViewForFileContentsTextBox " runat="server">
 <LoggedInTemplate>
 <p>
 <asp:TextBox ID="FileContents" runat="server" Rows="10"
 TextMode="MultiLine" Width="95%"></asp:TextBox>
 </p>
 </LoggedInTemplate>
</asp:LoginView>

Kontrol Web dalam templat LoginView tidak lagi dapat diakses langsung dari kelas code-behind. Misalnya, FilesGrid penanganan aktivitas dan RowDeleting GridView SelectedIndexChanged saat ini mereferensikan FileContents kontrol TextBox dengan kode seperti:

FileContents.Text = text;

Namun, kode ini tidak lagi valid. Dengan memindahkan FileContents Kotak Teks ke LoggedInTemplate kotak teks tidak dapat diakses secara langsung. Sebagai gantinya FindControl("controlId") , kita harus menggunakan metode untuk mereferensikan kontrol secara terprogram. Perbarui penanganan FilesGrid aktivitas untuk mereferensikan TextBox seperti ini:

TextBox FileContentsTextBox = LoginViewForFileContentsTextBox.FindControl("FileContents") as TextBox;
FileContentsTextBox.Text = text;

Setelah memindahkan TextBox ke LoginView LoggedInTemplate dan memperbarui kode halaman untuk mereferensikan TextBox menggunakan FindControl("controlId") pola, kunjungi halaman sebagai pengguna anonim. Seperti yang ditunjukkan FileContents Gambar 10, Kotak Teks tidak ditampilkan. Namun, View LinkButton masih ditampilkan.

Gambar 10: Kontrol LoginView Hanya Merender FileContents Kotak Teks untuk Pengguna Terautentikasi (Klik untuk melihat gambar ukuran penuh)

Salah satu cara untuk menyembunyikan tombol Tampilan untuk pengguna anonim adalah dengan mengonversi bidang GridView menjadi TemplateField. Ini akan menghasilkan templat yang berisi markup deklaratif untuk View LinkButton. Kita kemudian dapat menambahkan kontrol LoginView ke TemplateField dan menempatkan LinkButton dalam LoginView LoggedInTemplate, sehingga menyembunyikan tombol Tampilan dari pengunjung anonim. Untuk mencapai hal ini, klik tautan Edit Kolom dari Tag Pintar GridView untuk meluncurkan kotak dialog Bidang. Selanjutnya, pilih tombol Pilih dari daftar di sudut kiri bawah lalu klik tautan Konversi bidang ini ke TemplateField. Melakukannya akan mengubah markup deklaratif bidang dari:

<asp:CommandField SelectText="View" ShowSelectButton="True"/>

Kepada:

<asp:TemplateField ShowHeader="False">
 <ItemTemplate>
 <asp:LinkButton ID="LinkButton1" runat="server" CausesValidation="False"
 CommandName="Select" Text="View"></asp:LinkButton>
 </ItemTemplate>
</asp:TemplateField>

Pada titik ini, kita dapat menambahkan LoginView ke TemplateField. Markup berikut menampilkan Tampilan LinkButton hanya untuk pengguna terautentikasi.

<asp:TemplateField ShowHeader="False">
 <ItemTemplate>
 <asp:LoginView ID="LoginView1" runat="server">
 <LoggedInTemplate>
 <asp:LinkButton ID="LinkButton1" runat="server" CausesValidation="False"
 CommandName="Select" Text="View"></asp:LinkButton>
 </LoggedInTemplate>
 </asp:LoginView>
 </ItemTemplate>
</asp:TemplateField>

Seperti yang ditunjukkan Gambar 11, hasil akhir tidak secantik kolom Tampilan masih ditampilkan meskipun Tampilan LinkButtons di dalam kolom disembunyikan. Kita akan melihat cara menyembunyikan seluruh kolom GridView (dan bukan hanya LinkButton) di bagian berikutnya.

Gambar 11: Kontrol LoginView Menyembunyikan Tampilan LinkButtons untuk Pengunjung Anonim (Klik untuk melihat gambar ukuran penuh)

Fungsionalitas Pembatasan Terprogram

Dalam beberapa keadaan, teknik deklaratif tidak cukup untuk membatasi fungsionalitas ke halaman. Misalnya, ketersediaan fungsionalitas halaman tertentu mungkin tergantung pada kriteria di luar apakah pengguna yang mengunjungi halaman bersifat anonim atau diautentikasi. Dalam kasus seperti itu, berbagai elemen antarmuka pengguna dapat ditampilkan atau disembunyikan melalui cara terprogram.

Untuk membatasi fungsionalitas secara terprogram, kita perlu melakukan dua tugas:

1. Tentukan apakah pengguna yang mengunjungi halaman dapat mengakses fungsionalitas, dan
2. Ubah antarmuka pengguna secara terprogram berdasarkan apakah pengguna memiliki akses ke fungsionalitas yang dimaksud.

Untuk menunjukkan aplikasi kedua tugas ini, mari kita hanya mengizinkan Tito untuk menghapus file dari GridView. Tugas pertama kami, adalah menentukan apakah tito mengunjungi halaman. Setelah ditentukan, kita perlu menyembunyikan (atau menampilkan) kolom Hapus GridView. Kolom GridView dapat diakses melalui propertinya Columns ; kolom hanya dirender jika propertinya Visible diatur ke true (default).

Tambahkan kode berikut ke Page_Load penanganan aktivitas sebelum mengikat data ke GridView:

// Is this Tito visiting the page?
string userName = User.Identity.Name;
if (string.Compare(userName, "Tito", true) == 0)
    // This is Tito, SHOW the Delete column
    FilesGrid.Columns[1].Visible = true;
else
    // This is NOT Tito, HIDE the Delete column
    FilesGrid.Columns[1].Visible = false;

Seperti yang kita bahas dalam tutorial Gambaran Umum Autentikasi Formulir, User.Identity.Name mengembalikan nama identitas. Ini sesuai dengan nama pengguna yang dimasukkan dalam kontrol Masuk. Jika Tito mengunjungi halaman, properti kolom Visible kedua GridView diatur ke true; jika tidak, itu diatur ke false. Hasil bersihnya adalah bahwa ketika seseorang selain Tito mengunjungi halaman, baik pengguna terautentikasi lain atau pengguna anonim, kolom Hapus tidak dirender (lihat Gambar 12); namun, saat Tito mengunjungi halaman, kolom Hapus ada (lihat Gambar 13).

Gambar 12: Kolom Hapus Tidak Dirender Saat Dikunjungi Oleh Seseorang Selain Tito (seperti Bruce) (Klik untuk melihat gambar ukuran penuh)

Gambar 13: Kolom Hapus Dirender untuk Tito (Klik untuk melihat gambar ukuran penuh)

Langkah 4: Menerapkan Aturan Otorisasi ke Kelas dan Metode

Pada Langkah 3 kami melarang pengguna anonim untuk melihat konten file dan melarang semua pengguna tetapi Tito menghapus file. Hal ini dicapai dengan menyembunyikan elemen antarmuka pengguna terkait untuk pengunjung yang tidak sah melalui teknik deklaratif dan terprogram. Untuk contoh sederhana kami, menyembunyikan elemen antarmuka pengguna dengan benar sangat mudah, tetapi bagaimana dengan situs yang lebih kompleks di mana mungkin ada banyak cara berbeda untuk melakukan fungsionalitas yang sama? Dalam membatasi fungsionalitas tersebut kepada pengguna yang tidak sah, apa yang terjadi jika kita lupa menyembunyikan atau menonaktifkan semua elemen antarmuka pengguna yang berlaku?

Cara mudah untuk memastikan bahwa bagian fungsionalitas tertentu tidak dapat diakses oleh pengguna yang tidak sah adalah dengan menghias kelas atau metode tersebut PrincipalPermission dengan atribut . Ketika runtime .NET menggunakan kelas atau menjalankan salah satu metodenya, ia memeriksa untuk memastikan bahwa konteks keamanan saat ini memiliki izin untuk menggunakan kelas atau menjalankan metode . Atribut PrincipalPermission ini menyediakan mekanisme di mana kita dapat menentukan aturan ini.

Mari kita tunjukkan menggunakan PrincipalPermission atribut pada GridView SelectedIndexChanged dan RowDeleting penanganan aktivitas untuk melarang eksekusi oleh pengguna dan pengguna anonim selain Tito, masing-masing. Yang perlu kita lakukan adalah menambahkan atribut yang sesuai di atas setiap definisi fungsi:

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]
protected void FilesGrid_SelectedIndexChanged(object sender, EventArgs e)
{
    ...
}

[PrincipalPermission(SecurityAction.Demand, Name="Tito")]
protected void FilesGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
    ...
}

Atribut untuk SelectedIndexChanged penanganan aktivitas menentukan bahwa hanya pengguna yang diautentikasi yang dapat menjalankan penanganan aktivitas, di mana sebagai atribut pada RowDeleting penanganan aktivitas membatasi eksekusi ke Tito.

Jika, entah bagaimana, pengguna selain Tito mencoba menjalankan RowDeleting penanganan aktivitas atau pengguna yang tidak diautentikasi mencoba menjalankan SelectedIndexChanged penanganan aktivitas, runtime .NET akan menaikkan SecurityException.

Gambar 14: Jika Konteks Keamanan tidak Berwenang untuk Menjalankan Metode, dilemparkan SecurityException (Klik untuk melihat gambar ukuran penuh)

Catatan

Untuk mengizinkan beberapa konteks keamanan mengakses kelas atau metode, hiasi kelas atau metode dengan PrincipalPermission atribut untuk setiap konteks keamanan. Artinya, untuk memungkinkan Tito dan Bruce menjalankan penanganan RowDeleting aktivitas, tambahkan dua PrincipalPermission atribut:

[PrincipalPermission(SecurityAction.Demand, Name="Tito")]

[PrincipalPermission(SecurityAction.Demand, Name="Bruce")]

Selain halaman ASP.NET, banyak aplikasi juga memiliki arsitektur yang mencakup berbagai lapisan, seperti Logika Bisnis dan Lapisan Akses Data. Lapisan-lapisan ini biasanya diimplementasikan sebagai Pustaka Kelas dan menawarkan kelas dan metode untuk melakukan logika bisnis dan fungsionalitas terkait data. Atribut PrincipalPermission ini berguna untuk menerapkan aturan otorisasi ke lapisan ini.

Untuk informasi selengkapnya tentang menggunakan PrincipalPermission atribut untuk menentukan aturan otorisasi pada kelas dan metode, lihat entri blog Scott Guthrie Menambahkan Aturan Otorisasi ke Lapisan Bisnis dan Data Menggunakan PrincipalPermissionAttributes.

Ringkasan

Dalam tutorial ini kita melihat cara menerapkan aturan otorisasi berbasis pengguna. Kami mulai dengan melihat ASP. Kerangka kerja otorisasi URL NET. Pada setiap permintaan, mesin UrlAuthorizationModule ASP.NET memeriksa aturan otorisasi URL yang ditentukan dalam konfigurasi aplikasi untuk menentukan apakah identitas berwenang untuk mengakses sumber daya yang diminta. Singkatnya, otorisasi URL memudahkan untuk menentukan aturan otorisasi untuk halaman tertentu atau untuk semua halaman dalam direktori tertentu.

Kerangka kerja otorisasi URL menerapkan aturan otorisasi berdasarkan halaman demi halaman. Dengan otorisasi URL, identitas yang meminta berwenang untuk mengakses sumber daya tertentu atau tidak. Namun, banyak skenario meminta aturan otorisasi biji-bijian yang lebih halus. Daripada menentukan siapa yang diizinkan untuk mengakses halaman, kita mungkin perlu membiarkan semua orang mengakses halaman, tetapi untuk menampilkan data yang berbeda atau menawarkan fungsionalitas yang berbeda tergantung pada pengguna yang mengunjungi halaman. Otorisasi tingkat halaman biasanya melibatkan menyembunyikan elemen antarmuka pengguna tertentu untuk mencegah pengguna yang tidak sah mengakses fungsionalitas yang dilarang. Selain itu, dimungkinkan untuk menggunakan atribut untuk membatasi akses ke kelas dan eksekusi metodenya untuk pengguna tertentu.

Selamat Pemrograman!

Bacaan lebih lanjut

Untuk informasi selengkapnya tentang topik yang dibahas dalam tutorial ini, lihat sumber daya berikut:

• Menambahkan Aturan Otorisasi ke Lapisan Bisnis dan Data Menggunakan PrincipalPermissionAttributes
• Otorisasi ASP.NET
• Perubahan Antara Keamanan IIS6 dan IIS7
• Mengonfigurasi File dan Subdirektori Tertentu
• Membatasi Fungsionalitas Modifikasi Data Berdasarkan Pengguna
• Mulai Cepat Kontrol LoginView
• Memahami Otorisasi URL IIS7
• UrlAuthorizationModule Dokumentasi Teknis
• Bekerja dengan Data di ASP.NET 2.0

Tentang Penulis

Scott Mitchell, penulis beberapa buku ASP/ASP.NET dan pendiri 4GuysFromRolla.com, telah bekerja dengan teknologi Microsoft Web sejak 1998. Scott bekerja sebagai konsultan, pelatih, dan penulis independen. Buku terbarunya adalah Sams Teach Yourself ASP.NET 2.0 dalam 24 Jam. Scott dapat dijangkau di mitchell@4guysfromrolla.com atau melalui blognya di http://ScottOnWriting.NET.

Terima kasih khusus untuk

Seri tutorial ini ditinjau oleh banyak peninjau yang bermanfaat. Tertarik untuk meninjau artikel MSDN saya yang akan datang? Jika demikian, drop saya baris di mitchell@4GuysFromRolla.com.

SebelumnyaBerikutnya