AspNetDynamicApplications
1.0.0
Fitur keanggotaan ASP.NET mengurangi jumlah kode yang harus Anda tulis untuk mengotentikasi pengguna dan menyimpan kredensial mereka. Mengutip MSDN:
"Keanggotaan ASP.NET memberi Anda cara bawaan untuk memvalidasi dan menyimpan kredensial pengguna. Anda menggunakan keanggotaan ASP.NET dengan Formulir Otentikasi dan / atau dengan Kontrol Login ASP.NET untuk pengguna yang mengautentikasi."
Penyedia keanggotaan perlu ditentukan dalam file konfigurasi Web.config. Anda dapat menggunakan penyedia khusus Anda sendiri atau salah satu penyedia default yang dikirimkan dengan .NET Framework, seperti penyedia SQLMembershipprovider.
Semua data terkait pengguna disimpan dalam satu set tabel yang digunakan oleh sistem keanggotaan ASP.NET. Dalam kebanyakan kasus, Anda akan menggunakan satu set tabel per aplikasi web. Namun Anda juga dapat menggunakan kembali set yang sama untuk menyimpan kredensial pengguna dari beberapa aplikasi web. Ini secara efektif memungkinkan Anda untuk membuat satu aplikasi web yang bertindak sebagai portal yang memungkinkan Anda masuk ke salah satu aplikasi "virtual" ini.
Namun ini tidak mungkin di luar kotak. Anda memiliki beberapa pekerjaan di depan Anda, sebelum Anda dapat mendukung aplikasi dinamis seperti itu.
Mari kita mulai ...
Mari kita mulai dengan memeriksa entri web.config berikut:
Listing 1 - Web.config Asp.net Konfigurasi Keanggotaan
< membership defaultProvider = " SqlProvider " >
< providers >
< clear />
< add name = " SqlProvider "
type = " System.Web.Security.SqlMembershipProvider "
connectionStringName = " YourConnectionStringName "
applicationName = " MyApplication "
... />
</ providers >
</ membership >Pengaturan ini mengatur aplikasi web Anda untuk menggunakan SQLMembershipprovider untuk mengelola kredensial pengguna Anda. Semua data yang terkait dengan pengguna Anda disimpan dalam tabel keanggotaan ASP.NET default.
Komentar : Artikel ini bukan primer pada keanggotaan ASP.NET, Anda harus terbiasa dengannya. Gunakan alat pendaftaran ASP.NET SQL Server (ASPNET_REGSQL.EXE) untuk mengatur database Anda.
Seperti yang disebutkan sebelum Anda dapat menyimpan kredensial pengguna dari beberapa aplikasi web dalam set tabel yang sama. Setiap aplikasi web memisahkan data pengguna mereka dengan mempartisi mereka, dalam apa yang saya sebut, konteks aplikasi. Konteks aplikasi ini ditentukan oleh properti ApplicationName dari penyedia keanggotaan. Seperti yang dapat Anda lihat di Listing 1, nama aplikasi adalah "MyApplication".
SQLMembershipprovider menggunakan pengaturan ini untuk menentukan dalam konteks mana yang harus dioperasikan, semua data pengguna yang terkait dengan nama aplikasi ini akan dapat diakses oleh pustaka keanggotaan ASP.NET dan kontrol login.
Sayangnya pengaturan ini secara statis didefinisikan dalam web.config. Anda tidak dapat dengan mudah mengubahnya selama runtime. Jika Anda ingin mendukung aplikasi dinamis, Anda memerlukan cara untuk mengontrol nilai properti ApplicationName penyedia. Solusinya terletak pada membuat penyedia keanggotaan ASP.NET Anda sendiri.
SQLMembershipprovider mengambil nilai untuk properti ApplicationName dari pengaturan konfigurasi yang terkandung dalam file web.config. Kami ingin mengubah nilai yang dikembalikan oleh pengambil properti ini.
Ketika logging pada pengguna harus memperjelas niatnya, dengan kata lain ia harus menentukan aplikasi virtual mana yang ingin ia akses. Untuk tujuan ini saya mengharuskan pengguna tidak hanya menentukan nama pengguna dan kata sandi tetapi juga aplikasi virtual yang ingin ia akses. Dari sudut pandang pengguna, saya memanggil aplikasi virtual ini, domain.
Misalnya, misalkan Anda telah membuat database SQL Server yang disebut ASPNetMembership yang berisi tabel keanggotaan ASP.NET. Basis data ini berisi aplikasi virtual berikut yang ditentukan dalam tabel ASPNET_APPLICATION:
Setiap aplikasi virtual berisi pengguna dengan nama pengguna "cgeers". Sekarang jika saya ingin masuk ke aplikasi Northwind, saya harus memasukkan nama pengguna saya sebagai "Northwind cgeers". Untuk aplikasi AdventureWorks, ini adalah "AdventureWorks cgeers".
Bagian yang mendahului nama pengguna adalah nama aplikasi atau sejauh menyangkut pengguna, ini adalah domain yang harus ia masukkan untuk menentukan aplikasi virtual mana yang ingin ia akses. Domain dan nama pengguna dipisahkan oleh backslash.
Ketika pengguna log dalam menggunakan kontrol login ASP.NET, kami harus mengekstrak domain yang ia masukkan dan menyimpannya di lokasi yang dapat diakses oleh penyedia keanggotaan khusus kami. Namun kita harus memperhitungkan bahwa ASP.NET beroperasi di lingkungan yang multithreaded. Setiap permintaan yang diterima oleh ASP.NET ditangani oleh utas terpisah. Kami tidak dapat menyimpan domain di lokasi apa pun, permintaan masuk lainnya yang lain mungkin menimpanya. Itu harus terikat pada satu permintaan.
Tempat yang ideal untuk menyimpan informasi kontekstual yang terkait dengan permintaan individu adalah konteks HTTP saat ini. Informasi kontekstual ini dienkapsulasi oleh kelas HTTPContext.
Start Up Visual Studio dan buat solusi kosong baru yang disebut "Aspnetdynamicapplications". Selanjutnya tambahkan proyek perpustakaan kelas baru ke solusi bernama "cgeers.web.security". Tambahkan referensi ke rakitan System.configuration dan System.web. Penyedia khusus kami akan turun dari SQLMembershipprovider default sehingga referensi ini diperlukan.
Gambar 1 - Solusi Studio Visual
Ubah nama file Class1.CS yang dihasilkan secara otomatis ke DynamicApplicationsSQLMembershipprovider.cs dan tambahkan kode yang ditampilkan di Listing 2.
Listing 2 - DynamicApplicationsSQLMembershipprovider
public class DynamicApplicationsSqlMembershipProvider : SqlMembershipProvider
{
#region Fields
private const string ApplicationNameSetting = "ApplicationName" ;
#endregion
public override string ApplicationName
{
get
{
HttpContext context = HttpContext . Current ;
if ( context == null )
{
throw new InvalidOperationException ( "Http context cannot be null." ) ;
}
string applicationName = String . Empty ;
if ( context . Items . Contains ( ApplicationNameSetting ) )
{
if ( ! String . IsNullOrEmpty ( ( string ) context . Items [ ApplicationNameSetting ] ) )
{
applicationName = ( string ) context . Items [ ApplicationNameSetting ] ;
}
}
return applicationName ;
}
set
{
base . ApplicationName = value ;
}
}
}Seperti yang Anda lihat, penyedia keanggotaan khusus kami turun dari SQLMembershipprovider default dan mengesampingkan properti ApplicationName. Kami tidak peduli dengan setter, hanya dengan pengambil. Ketika penyedia membaca properti ApplicationName, kami mendapatkan pegangan ke konteks HTTP saat ini dengan memanggil properti statis saat ini dari kelas HTTPContext. Objek HTTPContext yang diperoleh memiliki properti Key/Value Collection yang disebut Item. Koleksi ini menyimpan nama aplikasi dalam entri yang diidentifikasi oleh kunci "ApplicationName". Nama kunci ini adalah sesuatu yang harus Anda tentukan pada waktu desain.
Sekarang setiap kali penyedia keanggotaan khusus kami perlu menentukan nama aplikasi yang disebut properti ApplicationName yang mengambil nilai dari konteks HTTP saat ini. Ini bekerja di lingkungan multithreaded ASP.NET karena setiap permintaan terkait dengan konteks HTTP sendiri.
Sekarang kami adalah penyedia keanggotaan khusus yang mengambil nilai untuk properti ApplicationName dari konteks HTTP Currect, kami masih harus mencari cara untuk benar -benar menyimpan nama aplikasi dalam konteks HTTP.
Pertama kali pengguna menentukan aplikasi virtual atau domain yang ingin dia akses adalah ketika dia masuk. Seperti yang disebutkan sebelumnya, pengguna harus memasukkan nama pengguna dalam format <domain><username> . Kita harus membuat kontrol login kita sendiri yang turun dari kontrol login ASP.NET. Setelah otentikasi pengguna, kita perlu mengekstrak domain yang dimasukkan dan menyimpannya dalam konteks HTTP saat ini.
Tambahkan proyek baru menggunakan template pustaka kelas ke solusi Anda yang disebut "cgeers.web.ui.webcontrols". Tambahkan referensi berikut ke proyek:
Selanjutnya hapus file class1.cs yang dihasilkan secara otomatis dan tambahkan kelas baru yang disebut DynamicApplicationsLogin. Karena kode untuk kelas ini cukup panjang, saya memilih untuk memecahnya menjadi beberapa daftar. Setelah setiap daftar penjelasan singkat tentang kode ditambahkan.
Listing 3 - DynamicApplicationslogin Control Private Properties
public class DynamicApplicationsLogin : Login
{
#region Fields
private string _fullUserName ;
#endregion
#region Properties
private string ApplicationName
{
get
{
string [ ] data = base . UserName . Split ( @"" . ToCharArray ( ) , 2 ) ;
string applicationName = ( data . Length == 2 ) ? data [ 0 ] : String . Empty ;
return applicationName ;
}
}
private string BaseUserName
{
get
{
string [ ] data = base . UserName . Split ( @"" . ToCharArray ( ) , 2 ) ;
string userName = ( data . Length == 2 ) ? data [ 1 ] : base . UserName ;
return userName ;
}
}
#endregion
// ...
}Karena Anda dapat melihat kontrol DynamicApplicationslogin turun dari kontrol login ASP.NET standar dan bidang yang disebut _fulluserName dan dua Properti Private ApplicationName dan BaseUserName ditambahkan.
Karena pengguna memasukkan domain dan nama pengguna ke dalam kontrol kotak teks yang sama, kita perlu membagi bagian -bagian ini. Seperti yang mungkin Anda tebak properti ApplicationName mengekstraksi domain dan nama dasar yang mengembalikan nama pengguna. Misalnya jika pengguna memasuki Northwind cgeers, properti ApplicationName akan mengembalikan "Northwind" dan properti BaseUserName akan mengembalikan "CGEERS".
Daftar 4 - Metode OnAuthenticated Kontrol DynamicApplicationslogin
protected override void OnAuthenticate ( AuthenticateEventArgs e )
{
HttpContext context = HttpContext . Current ;
if ( context == null )
{
throw new InvalidOperationException ( "Http context cannot be null." ) ;
}
MembershipProvider provider = Membership . Provider ;
if ( provider == null )
{
throw new InvalidOperationException ( "MembershipProvider cannot be null." ) ;
}
provider = provider as DynamicApplicationsSqlMembershipProvider ;
if ( provider == null )
{
throw new InvalidOperationException (
"The specified MembershipProvider must be of type DynamicApplicationsSqlMembershipProvider." ) ;
}
// Store the application name in the current Http context's items collections
context . Items [ "ApplicationName" ] = ApplicationName ;
// Validate the user
_fullUserName = UserName ;
UserName = BaseUserName ;
base . OnAuthenticate ( e ) ;
}Selanjutnya Anda perlu mengganti metode OnAuthenticate kontrol login untuk memastikan bahwa pengguna divalidasi di dalam konteks aplikasi yang benar (Aplikasi Virtual).
Pertama, metode ini mengambil referensi ke konteks HTTP saat ini, maka ia memeriksa apakah penyedia keanggotaan yang dimuat memang dinamis kustom kami SoalsqlMembershipprovider. Kemudian nama domain atau aplikasi yang dimasukkan disimpan dalam koleksi item konteks HTTP saat ini sehingga penyedia keanggotaan kami dapat mengambil nilai yang benar untuk properti ApplicationName -nya.
Last but not least nilai properti nama pengguna diatur hanya berisi nama pengguna dengan menetapkan properti baseUsername ke sana. Bidang Private _FulLusername sementara menyimpan nilai yang dimasukkan pengguna (domain username). Anda akan melihat bagaimana bidang ini digunakan nanti.
Setelah nama aplikasi disimpan dalam konteks HTTP dan properti nama pengguna hanya berisi nama pengguna, implementasi dasar disebut, ini menyebabkan nama pengguna divalidasi di dalam konteks aplikasi yang benar.
Listing 5 -DynamicApplicationslogin Control OnloginError Metode
protected override void OnLoginError ( EventArgs e )
{
UserName = _fullUserName ;
base . OnLoginError ( e ) ;
}Menggantikan metode OnloginError dan sebelum memanggil implementasi dasar menetapkan bidang _fulluserName ke properti nama pengguna. Saat mengautentikasi pengguna (metode onAuthenticate) properti nama pengguna hanya boleh berisi nama pengguna dan bukan domain, tetapi ketika otentikasi gagal, Anda perlu memastikan bahwa teks yang dimasukkan pengguna dalam kontrol kotak teks yang mewakili nama pengguna diatur ulang ke nilai yang dimasukkan pengguna. WHISE mungkin membingungkan bagi pengguna jika domain yang dia masukkan menghilang.
Listing 6 - Metode Onloggedin Kontrol DynamicApplicationslogin
protected override void OnLoggedIn ( EventArgs e )
{
UserName = _fullUserName ;
HttpContext context = HttpContext . Current ;
if ( context == null )
{
throw new InvalidOperationException ( "Http context cannot be null." ) ;
}
string userName = BaseUserName ;
MembershipUser user = Membership . GetUser ( userName ) ;
if ( user != null )
{
string userData = String . Format ( "AN={0};" , ApplicationName ) ;
HttpCookie cookie = FormsAuthenticationHelper . StoreUserDataInAuthenticationCookie (
userName , userData , RememberMeSet
) ;
// Manually add the cookie to the Cookies collection
context . Response . Cookies . Add ( cookie ) ;
}
}Untuk menyelesaikan Kontrol DynamicApplicationslogin, Anda perlu mengganti metode onloggedin. Nama aplikasi disimpan di properti userData dari FormsAuthenticationTicket. Tiket otentikasi ini digunakan oleh otentikasi formulir untuk mengidentifikasi pengguna yang diautentikasi. Di sini kami menyimpannya di cookie dan menambahkannya ke respons konteks HTTP saat ini. Kemudian, Anda akan melihat mengapa ini diperlukan.
Anda melihat Listing 6, Anda akan melihat bahwa cookie yang berisi Tiket Otentikasi Formulir dibuat oleh kelas pembantu yang disebut FormsAuthenticationHelper. Ini adalah kelas pembantu statis yang hanya berisi satu metode, yaitu StoreUserDatainAuthenticationCookie.
Tambahkan kelas baru yang disebut FormsAuthenticationHelper ke CGEERS.Web.Security Project dan tambahkan kode yang ditampilkan dalam Listing 7.
Listing 7 - FormsAuthenticationHelper
public static class FormsAuthenticationHelper
{
public static HttpCookie StoreUserDataInAuthenticationCookie (
string userName , string userData , bool persistent )
{
if ( String . IsNullOrEmpty ( userName ) )
{
throw new InvalidOperationException ( "UserName cannot be null or empty." ) ;
}
if ( String . IsNullOrEmpty ( userData ) )
{
throw new InvalidOperationException ( "User data cannot be null or empty." ) ;
}
// Create the cookie that contains the forms authentication ticket
HttpCookie cookie = FormsAuthentication . GetAuthCookie ( userName , persistent ) ;
// Get the FormsAuthenticationTicket out of the encrypted cookie
FormsAuthenticationTicket ticket = FormsAuthentication . Decrypt ( cookie . Value ) ;
// Create a new FormsAuthenticationTicket that includes our custom user data
FormsAuthenticationTicket newTicket = new FormsAuthenticationTicket ( ticket . Version ,
ticket . Name ,
ticket . IssueDate ,
ticket . Expiration ,
persistent ,
userData ) ;
// Update the cookie's value to use the encrypted version of our new ticket
cookie . Value = FormsAuthentication . Encrypt ( newTicket ) ;
// Return the cookie
return cookie ;
}
}Metode StoreUserDatainAuthenticationCookie (...) mengambil cookie untuk pengguna yang ditentukan (parameter nama pengguna) yang berisi tiket otentikasi formulir. Selanjutnya cookie didekripsi untuk mengakses objek FormsAuthenticationTicket. Kemudian FormsAuthenticationTicket baru dibuat berdasarkan tiket lama dan nilainya yang terkandung dalam parameter UserData disimpan dalam tiket ini. Sebagai langkah terakhir, objek FormsAuthenticationTicket baru disimpan dalam cookie terenkripsi.
Komentar : DynamicApplicationslogin Control Stores mengirimkan cookie ini kembali ke pengguna, sehingga klien perlu mendukung cookie!
Mari kita rekapitulasi apa yang kita miliki sejauh ini.
Jadi kami memiliki penyedia keanggotaan khusus yang dapat, per permintaan, untuk menentukan konteks aplikasi untuk beroperasi dan kami memiliki kontrol login khusus yang mengidentifikasi konteks ini dengan mengharuskan pengguna mendahului nama pengguna mereka dengan domain (= nama aplikasi).
Ini berfungsi dengan baik jika aplikasi web Anda hanya terdiri dari halaman login. Ingatlah bahwa penyedia keanggotaan khusus menentukan konteks aplikasi dengan membaca nama aplikasi yang disimpan dalam konteks HTTP saat ini. Dengan setiap permintaan yang Anda buat, konteks HTTP baru dibuat. Ketika logging dalam nama aplikasi secara eksplisit disimpan dalam konteks HTTP. Namun untuk permintaan selanjutnya, ini bukan masalahnya. Entah bagaimana kami harus memastikan bahwa konteks HTTP diinisialisasi dengan benar dengan nama aplikasi dengan setiap permintaan setelah pengguna masuk.
Seperti yang disebutkan sebelumnya, Kontrol DynamicApplicationLogin mengirimkan cookie terenkripsi kepada pengguna setelah berhasil masuk. Cookie ini berisi nama aplikasi dan dikirim bersama dengan setiap permintaan berikutnya. Voila, sekarang yang kita butuhkan adalah cara untuk memasukkan beberapa logika ke dalam pipa permintaan ASP.NET, untuk membaca isi cookie ini dan menyimpan nama aplikasi yang diambil dalam konteks HTTP.
Modul HTTP sangat cocok untuk situasi ini. Modul HTTP dipanggil pada setiap permintaan dan berjalan sebelum dan sesudah permintaan diproses.
Tambahkan kelas baru yang disebut DynamicApplicationsModule ke proyek CGEERS.Web.Security. Kelas ini perlu mengimplementasikan antarmuka IHTTPModule. Kode untuk modul HTTP ini ditampilkan di Listing 8.
Listing 8 - DynamicApplicationsModule
public class DynamicApplicationsModule : IHttpModule
{
#region Fields
private const string ApplicationNameSetting = "ApplicationName" ;
#endregion
#region IHttpModule Members
public void Dispose ( )
{ }
public void Init ( HttpApplication context )
{
context . AuthenticateRequest += DetermineApplicationName ;
}
#endregion
private static void DetermineApplicationName ( object sender , EventArgs e )
{
// Access the current Http application.
HttpApplication application = sender as HttpApplication ;
if ( application == null )
{
throw new InvalidOperationException ( "Http application cannot be null." ) ;
}
// Get the HttpContext for the current request.
HttpContext context = application . Context ;
if ( context == null )
{
throw new InvalidOperationException ( "Http context cannot be null." ) ;
}
// Read the application name stored in the FormsAuthenticationTicket
string applicationName = String . Empty ;
if ( context . Request . IsAuthenticated )
{
FormsIdentity identity = context . User . Identity as FormsIdentity ;
if ( identity != null )
{
FormsAuthenticationTicket ticket = identity . Ticket ;
if ( ticket != null )
{
applicationName = ticket . GetApplicationName ( ) ;
}
}
}
// Store the application name in the Items collection of the per-request http context.
// Storing it in the session state is not an option as the session is not available at this
// time. It is only available when the Http application triggers the AcquireRequestState event.
context . Items [ ApplicationNameSetting ] = applicationName ;
}
}Metode init (...) menginisialisasi modul HTTP dan menyiapkannya untuk menangani permintaan. Di sini acara HTTPapplication's AuthenticateRequest terhubung ke penangan acara DetermineApplicationName.
Event Handler DetermineApplicationName (...) memeriksa apakah itu berurusan dengan permintaan yang diautentikasi dan jika demikian mengambil tiket FormsAuthentication yang dikirim bersama oleh klien.
Tiket ini mengidentifikasi konteks aplikasi untuk beroperasi. Nama aplikasi diekstraksi dari tiket menggunakan metode FormsAuthenticationTicket's getApplicationName (). Ini adalah metode ekstensi, saya akan mengatasinya di bagian berikut.
Akhirnya setelah mengekstraksi nama aplikasi dari tiket itu disimpan dalam konteks HTTP sehingga penyedia keanggotaan khusus kami dapat membacanya.
Tambahkan kelas baru yang disebut FormsAuthenticationTickeTextensions ke proyek CGEERS.WEB.SECURITY dan tambahkan kode yang ditampilkan dalam Listing 9.
Listing 9 - FormsAuthenticationTickeTextensions
internal static class FormsAuthenticationTicketExtensions
{
public static string GetApplicationName ( this FormsAuthenticationTicket ticket )
{
// Check if the application name (AN=) is stored in the ticket's userdata.
string applicationName = String . Empty ;
List < string > settings = new List < string > ( ticket . UserData . Split ( ';' ) ) ;
foreach ( string s in settings )
{
string setting = s . Trim ( ) ;
if ( setting . StartsWith ( "AN=" ) )
{
int startIndex = setting . IndexOf ( "AN=" ) + 3 ;
applicationName = setting . Substring ( startIndex ) ;
break ;
}
}
return applicationName ;
}
}Seperti yang dapat Anda lihat di Listing 6 Kontrol DynamicApplicationLogin menyimpan nama aplikasi di properti UserData dari FormsAuthenticationTicket dengan mendahuluinya dengan awalan "an =". Dengan demikian metode ekstensi ini perlu memperhitungkan hal ini saat mengambil nama aplikasi dari FormsAuthenticationTicket.
Komentar : Jangan ragu untuk meningkatkan cara nama aplikasi disimpan dalam tiket, tetapi ingat untuk mengimplementasikan sistem yang sama untuk kontrol DynamicApplicationslogin dan metode ekstensi ini.
Mirip dengan Kontrol DynamicApplicationslogin yang telah saya buat kontrol yang turun dari Asp.net PasswordRecovery dan ChangePassword Controls. Jika Anda ingin pengguna dapat mengambil kata sandi dan/atau mengubahnya, maka Anda perlu menggunakan kontrol ini. Mereka memastikan bahwa semuanya dieksekusi dalam konteks aplikasi yang benar.
Implementasinya sangat mirip dengan kontrol DynamicApplicationslogin sehingga saya tidak akan mencantumkan kode kontrol ini di sini. Jika Anda ingin memeriksa kode sumber kontrol ini, maka unduh kode sumber yang menyertai artikel ini. Anda dapat menemukan kontrol ini di proyek CGEER.WEB.UI.WebControls.
Kode sumber yang menyertai artikel ini juga berisi proyek aplikasi web demo yang menunjukkan DynamicApplicationsSqlMembershipprovider, kontrol login baru, modul http khusus kami ... dan sebagainya.
Gambar 2 - Solusi Studio Visual
Untuk menjalankan aplikasi demo ini, ikuti langkah -langkah ini:
Setelah mengikuti langkah -langkah ini, Anda harus siap menjalankan aplikasi web demo. Anda membuat database yang berisi dua aplikasi dan pengguna untuk setiap aplikasi.
Saat Anda memulai aplikasi web, Anda dapat masuk ke setiap aplikasi dengan menentukan nama aplikasi (domain) diikuti oleh backslash dan nama pengguna. Tentu saja kata sandi pengguna juga diperlukan.
Kontrol login yang kami buat mengurus sisanya dan pastikan bahwa Anda beroperasi dalam konteks aplikasi yang benar. Setiap panggilan selanjutnya dengan perpustakaan keanggotaan ASP.NET akan memicu penyedia keanggotaan khusus untuk mengembalikan nama aplikasi yang benar sehingga memastikan panggilan ini beroperasi dalam konteks aplikasi yang benar.
Komentar : File Web.config aplikasi web demo berisi komentar yang menentukan semua yang perlu Anda lakukan untuk mengatur aplikasi dengan benar. Pastikan untuk memeriksanya.
Artikel ini menunjukkan kepada Anda bagaimana dapat menggunakan sistem keanggotaan ASP.NET untuk membuat aplikasi portal yang memungkinkan pengguna masuk ke salah satu dari banyak aplikasi virtual.
Kunci pertama untuk mewujudkan ini adalah membuat penyedia keanggotaan khusus yang memastikan Anda beroperasi dalam konteks aplikasi yang benar dengan mengambil nilai untuk properti ApplicationName dari lokasi penyimpanan yang terkait dengan permintaan individu.
Dengan membuat kontrol login khusus yang turun dari kontrol login ASP.NET standar, kami dapat menentukan aplikasi mana yang ingin diakses pengguna.
Dengan merangkum informasi ini dalam cookie terenkripsi, kami dapat secara otomatis mengidentifikasi aplikasi yang ingin diakses pengguna untuk setiap permintaannya.
