AspNetDynamicApplications
1.0.0
Die ASP.NET -Mitgliedschaftsfunktion reduziert die Menge an Code, die Sie schreiben müssen, um Benutzer zu authentifizieren und ihre Anmeldeinformationen zu speichern. MSDN zitieren:
"Mit der ASP.NET-Mitgliedschaft können Sie Benutzeranmeldeinformationen integriert und speichern.
Der Mitgliedschaftsanbieter muss in der Konfigurationsdatei web.config angegeben werden. Sie können Ihren eigenen benutzerdefinierten Anbieter oder einen der Standardanbieter verwenden, die mit dem .NET -Framework geliefert werden, z.
Alle benutzerbezogenen Daten werden in einer Reihe von Tabellen gespeichert, die vom ASP.NET -Mitgliedschaftssystem verwendet werden. In den meisten Fällen verwenden Sie einen Satz von Tabellen pro Webanwendung. Sie können jedoch auch denselben Satz wiederverwenden, um die Benutzeranmeldeinformationen mehrerer Webanwendungen zu speichern. Dadurch können Sie eine Webanwendung erstellen, die als Portal fungiert, mit der Sie sich bei einer dieser "virtuellen" Anwendungen anmelden können.
Dies ist jedoch nicht möglich. Sie haben einige Arbeit vor Ihnen, bevor Sie solche dynamischen Anwendungen unterstützen können.
Lass uns anfangen ...
Beginnen wir zunächst den folgenden Web.config -Eintrag:
Listing 1 - Web.config ASP.NET -Mitgliedschaftskonfiguration
< membership defaultProvider = " SqlProvider " >
< providers >
< clear />
< add name = " SqlProvider "
type = " System.Web.Security.SqlMembershipProvider "
connectionStringName = " YourConnectionStringName "
applicationName = " MyApplication "
... />
</ providers >
</ membership >In diesen Einstellungen werden Ihre Webanwendung so eingerichtet, dass Sie mit dem SQLMumbersShipProvider Ihre Benutzeranmeldeinformationen verwalten können. Alle Daten, die sich auf Ihre Benutzer beziehen, werden in den Standard -ASP.NET -Mitgliedschaftstabellen gespeichert.
Bemerkung : Dieser Artikel ist keine Grundierung für die ASP.NET -Mitgliedschaft, Sie sollten damit vertraut sein. Verwenden Sie das ASP.NET SQL Server -Registrierungstool (ASPNET_regsql.exe), um Ihre Datenbank einzurichten.
Wie bereits erwähnt, können Sie die Benutzeranmeldeinformationen mehrerer Webanwendungen in denselben Tabellenmenge speichern. Jede Webanwendung trennt ihre Benutzerdaten, indem sie sie in dem, was ich nenne, einen Anwendungskontext partitioniert. Dieser Anwendungskontext wird durch die Anwendungsname -Eigenschaft des Mitgliedsanbieters definiert. Wie Sie in Listing 1 sehen können, lautet der Anwendungsname "MyApplication".
Der SQLMumbersShipProvider verwendet diese Einstellung, um zu bestimmen, in welchem Kontext er betrieben wird. Alle Benutzerdaten, die an diesen Anwendungsnamen gebunden sind, können von der ASP.NET -Mitgliedsbibliothek und der Anmeldesteuerungen zugegriffen werden.
Leider ist diese Einstellung statisch im web.config definiert. Sie können es während der Laufzeit nicht leicht ändern. Wenn Sie dynamische Anwendungen unterstützen möchten, benötigen Sie eine Möglichkeit, den Wert der Anwendungsname -Eigenschaft des Anbieters zu steuern. Die Lösung liegt in der Erstellung Ihres eigenen ASP.NET -Mitgliedsanbieters.
Der SQLMemberShipProvider ruft den Wert für seine Anwendungsname -Eigenschaft aus den in der Web.config -Datei enthaltenen Konfigurationseinstellungen ab. Wir möchten den Wert ändern, den der Getter dieser Immobilie zurückgibt.
Wenn Sie sich im Benutzer anmelden, sollte er seine Absichten klar machen, mit anderen Worten, er muss angeben, auf welche der virtuellen Anwendungen er zugreifen möchte. Zu diesem Zweck verlange ich, dass der Benutzer nicht nur seinen Benutzernamen und sein Passwort, sondern auch die virtuelle Anwendung angibt, auf die er zugreifen möchte. Aus Sicht des Benutzers nenne ich diese virtuelle Anwendung, die Domain.
Angenommen, Sie haben eine SQL -Server -Datenbank mit dem Namen ASPNETMembership erstellt, die die ASP.NET -Mitgliedschaftstabellen enthält. Diese Datenbank enthält die folgenden virtuellen Anwendungen, die in der Tabelle ASPNET_Applications definiert sind:
Jede virtuelle Anwendung enthält einen Benutzer mit dem Benutzernamen "Cgeers". Wenn ich mich jetzt bei der Northwind -Anwendung anmelden möchte, muss ich meinen Benutzernamen als "Northwind cgeers" eingeben. Für die AdventureWorks -Anwendung wären dies "AdventureWorks Cgeers".
Der Teil des Benutzernamens ist der Anwendungsname oder soweit der Benutzer dies betrifft, dass dies die Domäne ist, die er eingeben muss, um anzugeben, auf welche virtuelle Anwendung er zugreifen möchte. Die Domäne und der Benutzername werden durch einen Backslash getrennt.
Wenn sich der Benutzer bei der Verwendung der ASP.NET -Anmeldesteuerung anmeldet, müssen wir die von ihm eingegebene Domäne extrahieren und an einem Ort speichern, auf den unser benutzerdefinierter Mitgliedschaftsanbieter zugreifen kann. Wir müssen jedoch berücksichtigen, dass ASP.NET in einer Multithread -Umgebung arbeitet. Jede von ASP.NET empfangene Anfrage wird von einem separaten Thread behandelt. Wir können die Domain nicht an jedem Ort speichern. Andere Whise andere eingehende Anfragen können sie möglicherweise überschreiben. Es muss an eine einzige Anfrage gebunden sein.
Der ideale Ort, um Kontextinformationen zu speichern, die an eine individuelle Anfrage gebunden sind, ist der aktuelle HTTP -Kontext. Diese kontextbezogene Informationen werden von der HTTPContext -Klasse verkörpert.
Starten Sie Visual Studio und erstellen Sie eine neue leere Lösung namens "Aspnetdynamicapplications". Fügen Sie als nächstes ein neues Klassenbibliotheksprojekt zu der Lösung mit dem Namen "Cgeers.Web.security" hinzu. Fügen Sie Verweise auf das System.Configuration und System.Web Assemblys hinzu. Unser benutzerdefinierter Anbieter steigt vom Standard SQLMumbersShipProvider ab, sodass diese Referenzen erforderlich sind.
Abbildung 1 - Visual Studio -Lösung
Benennen Sie die automatisch generierte Klasse1.cs -Datei in dynamicApplicationsSQLMemberShipProvider.cs um und fügen Sie den in Listing 2 gezeigten Code hinzu.
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 ;
}
}
}Wie Sie sehen können, steigt unser benutzerdefinierter Mitgliedschaftsanbieter von der Standard -SQLMemberShipProvider ab und überschreibt die Anwendungsname -Eigenschaft. Wir sind nicht mit dem Setter besorgt, nur mit dem Getter. Wenn der Anbieter die Anwendungsname -Eigenschaft liest, erhalten wir den aktuellen HTTP -Kontext, indem wir die statische aktuelle Eigenschaft der HTTPContext -Klasse aufrufen. Das erhaltene HTTPContext -Objekt verfügt über eine Key/Value Collection -Eigenschaft, die als Elemente bezeichnet wird. Diese Sammlung speichert den Anwendungsnamen in einem Eintrag, der vom Schlüssel "ApplicationName" identifiziert wurde. Der Name dieses Schlüssels ist etwas, das Sie zur Entwurfszeit bestimmen müssen.
Jedes Mal, wenn unser benutzerdefinierter Mitgliedschaftsanbieter den Anwendungsnamen ermitteln muss, ruft er die Anwendungsname -Eigenschaft auf, die den Wert aus dem aktuellen HTTP -Kontext abruft. Dies funktioniert in der Multithread -Umgebung von ASP.NET, da jede Anfrage an einen eigenen HTTP -Kontext gebunden ist.
Nachdem wir nun ein benutzerdefinierter Mitgliedschaftsanbieter, der den Wert für seine Anwendungsname -Eigenschaft aus dem Currect HTTP -Kontext abruft, müssen wir noch einen Weg finden, den Anwendungsnamen im HTTP -Kontext tatsächlich zu speichern.
Das erste Mal, dass ein Benutzer die virtuelle Anwendung oder Domain angibt, auf die er zugreifen möchte, ist, wenn er sich anmeldet. Wie bereits erwähnt, muss der Benutzer seinen Benutzernamen im Format <domain><username> eingeben. Wir müssen unsere eigene Anmeldesteuerung erstellen, die von der ASP.NET -Anmeldesteuerung herabsteigt. Bei der Benutzerauthentifizierung müssen wir die eingegebene Domäne extrahieren und im aktuellen HTTP -Kontext speichern.
Fügen Sie ein neues Projekt mit der Klassenbibliotheksvorlage zu Ihrer Lösung "cgeers.web.ui.webcontrols" hinzu. Fügen Sie die folgenden Verweise zum Projekt hinzu:
Löschen Sie als Nächstes die automatisch generierte Class1.cs -Datei und fügen Sie eine neue Klasse namens DynamicApplicationsLogin hinzu. Da der Code für diese Klasse ziemlich lang ist, habe ich mich entschieden, ihn in mehrere Auflistungen zu unterteilen. Nach jeder Auflistung wird eine kurze Erläuterung des Codes hinzugefügt.
Auflistung 3 - DynamicApplicationsLogin Control Private Eigenschaften
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
// ...
}Wie Sie sehen können, steigt die DynamicApplicationsLogin -Steuerung vom Standard -ASP.NET -Anmeldesteuerung ab und ein Feld namens _fulLusername und zwei private Eigenschaften ApplicationName und BaseUnername werden hinzugefügt.
Da der Benutzer die Domain und den Benutzernamen in das gleiche Textbox -Steuerelement eingibt, müssen wir diese Teile aufteilen. Wie Sie vielleicht erraten, extrahiert die Anwendungsname -Eigenschaft die Domäne und der Basisusername gibt den Benutzernamen zurück. Wenn der Benutzer beispielsweise Northwind cgeers eingibt, würde die Anwendungsname -Eigenschaft "Northwind" zurückgeben, und das BasisUnername -Grundstück würde "cgeers" zurückgeben.
Auflistung 4 - DynamicApplicationslogin -Steuerung OnAuthenticate -Methode
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 ) ;
}Als nächstes müssen Sie die OnAuthenticate -Methode der Anmeldung überschreiben, um sicherzustellen, dass der Benutzer im richtigen Anwendungskontext (virtuelle Anwendung) validiert ist.
Zunächst ruft diese Methode einen Verweis auf den aktuellen HTTP -Kontext ab und überprüft dann, ob der geladene Mitgliedschaftsanbieter tatsächlich unsere benutzerdefinierte DynamicCapplicationsSQLMemberSProvider ist. Anschließend wird die eingegebene Domäne oder Anwendungsname in der aktuellen Sammlung des HTTP -Kontext -Elements gespeichert, sodass unser Mitgliedschaftsanbieter den richtigen Wert für seine Anwendungsname -Eigenschaft abrufen kann.
Nicht zuletzt wird der Wert der Benutzernamen -Eigenschaft so festgelegt, dass der Benutzername nur durch Zuweisen der BasisUnername -Eigenschaft ihm zugewiesen wird. Das private Feld private _fulLusername speichert den Wert, den der Benutzer eingegeben hat, vorübergehend (Domain Benutzername). Sie werden sehen, wie dieses Feld später verwendet wird.
Nachdem der Anwendungsname im HTTP -Kontext gespeichert wurde und die Benutzername -Eigenschaft nur den Benutzernamen enthält, der die Basisimplementierung aufgerufen wird. Dies führt dazu, dass der Benutzername im korrekten Anwendungskontext validiert wird.
Listing 5 -Dynamicapplications -Login -Steuerung OnloGinError -Methode
protected override void OnLoginError ( EventArgs e )
{
UserName = _fullUserName ;
base . OnLoginError ( e ) ;
}Überschreiben Sie die OnLoginError -Methode und weisen Sie vor dem Aufrufen der Basisimplementierung dem Feld _fulLusername der Benutzernameneigenschaft zu. Bei der Authentifizierung des Benutzers (OnAuthenticate -Methode) darf die Benutzername -Eigenschaft nur den Benutzernamen und nicht den Domäne enthalten. Wenn die Authentifizierung jedoch fehlschlägt, müssen Sie sicherstellen, dass der in der Benutzername eingegebene Text der Benutzer, der den Benutzernamen darstellt, auf den Wert zurückgesetzt wird, den der Benutzer anfänglich eingegeben hat. Other Whise Es könnte für den Benutzer verwirrend sein, wenn die von ihm eingegebene Domäne verschwindet.
Listing 6 - DynamicApplicationsLogin -Steuerungsmethode Onloggedin -Methode
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 ) ;
}
}Um die DynamicApplicationsLogin -Steuerung zu beenden, müssen Sie die Onloggedin -Methode überschreiben. Der Anwendungsname wird in der userData -Eigenschaft eines FormsAuthenticationTicket gespeichert. Dieses Authentifizierungs -Ticket wird von Forms Authentifizierung verwendet, um einen authentifizierten Benutzer zu identifizieren. Hier speichern wir es in einem Cookie und fügen es der aktuellen Antwort des HTTP -Kontextes hinzu. Später werden Sie sehen, warum dies erforderlich ist.
Sie werfen einen Blick auf die Auflistung 6, Sie werden feststellen, dass das Cookie mit dem Formulierungsauthentifizierungs -Ticket von einer Helferklasse namens FormsAuthenticationHelper erstellt wird. Dies ist eine statische Helferklasse, die nur eine Methode enthält, nämlich StoreUserDatainAuthenticationcookie.
Fügen Sie eine neue Klasse namens FormsAuthenticationHelper zu den cgeers.web.Security -Projekt hinzu und fügen Sie den in Listing 7 gezeigten Code hinzu.
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 ;
}
}Die StoreUserDatainAuthenticationCookie (...) -Methode ruft das Cookie für den angegebenen Benutzer (Benutzername -Parameter) ab, der das Formsauthentifizierungs -Ticket enthält. Als nächstes wird der Cookie entschlüsselt, um auf das FormsauthenticationTicket -Objekt zuzugreifen. Anschließend wird eine neue FormsauthenticationTicket basierend auf dem alten Ticket erstellt und der im Parameter UserData enthaltene Wert wird in diesem Ticket gespeichert. In einem letzten Schritt wird das neue FormsauthenticationTicket -Objekt in einem verschlüsselten Cookie gespeichert.
Bemerkung : Die DynamicApplicationsLogin Control Stores sendet diesen Cookie zurück an den Benutzer, sodass der Client Cookies unterstützen muss!
Lassen Sie uns rekapitulieren, was wir bisher haben.
Wir haben also unseren benutzerdefinierten Mitgliedschaftsanbieter, der pro Anfrage in der Lage ist, den Anwendungskontext zu bestimmen, in dem wir arbeiten können, und wir haben eine benutzerdefinierte Anmeldesteuerung, die diesen Kontext identifiziert, indem sie verlangt, dass Benutzer ihrem Benutzernamen mit einer Domain (= Anwendungsname) vorausgehen.
Dies funktioniert recht gut, wenn Ihre Webanwendung nur aus einer Anmeldeseite besteht. Denken Sie daran, dass der benutzerdefinierte Mitgliedsanbieter den Anwendungskontext festgelegt hat, indem der im aktuelle HTTP -Kontext gespeicherte Anwendungsname gelesen wird. Mit jeder Anfrage, die Sie stellen, wird ein neuer HTTP -Kontext erstellt. Wenn sich die Anmeldung im Anwendungsnamen ausdrücklich im HTTP -Kontext speichert. Bei nachfolgenden Anfragen ist dies jedoch nicht der Fall. Irgendwie müssen wir sicherstellen, dass der HTTP -Kontext mit dem Anwendungsnamen mit jeder Anforderung korrekt initialisiert wird, nachdem sich der Benutzer angemeldet hat.
Wie bereits erwähnt, sendet das DynamicApplicationogin -Steuerelement ein verschlüsseltes Cookie an den Benutzer, nachdem er erfolgreich angemeldet wurde. Dieses Cookie enthält den Anwendungsnamen und wird zusammen mit jeder nachfolgenden Anforderung gesendet. Voila, jetzt brauchen wir nur noch eine Möglichkeit, eine Logik in die ASP.NET -Anforderungspipeline einzufügen, um den Inhalt dieses Cookies zu lesen und den abgerufenen Anwendungsnamen im HTTP -Kontext zu speichern.
Ein HTTP -Modul ist perfekt für diese Situation. Ein HTTP -Modul wird auf jede Anfrage aufgefordert und wird vor und nach einer Anfrage ausgeführt.
Fügen Sie eine neue Klasse namens DynamicApplicationsModule zum Cgeers.Web.Security -Projekt hinzu. Diese Klasse muss die IHTTPModule -Schnittstelle implementieren. Der Code für dieses HTTP -Modul wird in Listing 8 angezeigt.
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 ;
}
}Die Init (...) -Methode initialisiert ein HTTP -Modul und bereitet es auf Anforderungen vor. Hier ist das authenticateRequest -Ereignis der Httpapplication an den DeterminenapplicationName -Ereignis -Handler süchtig.
Der Ereignishandler des DetermineApplicationName (...) prüft, ob es sich um eine authentifizierte Anfrage handelt und wenn dies das vom Kunden gesendete Formsauthentication -Ticket abgerufen hat.
Dieses Ticket identifiziert den Anwendungskontext, in dem er betrieben werden soll. Der Anwendungsname wird aus dem Ticket unter Verwendung der FormsAuthenticationTicket -Methode von GetApplicationName () extrahiert. Dies ist eine Erweiterungsmethode, ich werde sie im folgenden Abschnitt ansprechen.
Nachdem er den Anwendungsnamen aus dem Ticket extrahiert hat, wird es schließlich im HTTP -Kontext gespeichert, damit unser benutzerdefinierter Mitgliedschaftsanbieter ihn lesen kann.
Fügen Sie eine neue Klasse namens FormsAuthenticationTicketExtensionen zu den cgeers.web.Security -Projekt hinzu und fügen Sie den in Listing 9 gezeigten Code hinzu.
Listing 9 - FormsAuthenticationTicketExtensionen
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 ;
}
}Wie Sie in Auflistung 6 sehen können, speichert die DynamicApplicationogin -Steuerung den Anwendungsnamen in der Benutzerdata -Eigenschaft der FormsAuthenticationTicket, indem Sie ihn mit dem Präfix "an =" vorab vorangetrieben. Daher muss diese Erweiterungsmethode dies berücksichtigen, wenn der Anwendungsname von einem FormsAuthenticationTicket abgerufen wird.
Bemerkung : Fühlen Sie sich frei, die Art und Weise zu verbessern, wie der Anwendungsname innerhalb des Tickets gespeichert ist, aber denken Sie daran, dasselbe System für die DynamicApplicationsLogin -Steuerung und diese Erweiterungsmethode zu implementieren.
Ähnlich wie bei der DynamicApplicationsLogin -Steuerung habe ich Steuerelemente erstellt, die von den Steuerelementen von ASP.NET Password- und ChangePassword absteigen. Wenn ein Benutzer in der Lage sein kann, sein Passwort abzurufen und/oder es zu ändern, müssen Sie diese Steuerelemente verwenden. Sie stellen sicher, dass alles im richtigen Anwendungskontext ausgeführt wird.
Die Implementierung ist der der DynamicicapplicationsLogin -Steuerung sehr ähnlich, sodass ich den Code dieser Steuerelemente hier nicht auflisten werde. Wenn Sie den Quellcode dieser Steuerelemente überprüfen möchten, laden Sie den Quellcode, der diesen Artikel begleitet, herunter. Sie finden diese Steuerelemente im Projekt von Cgeers.web.Ui.Webcontrols.
Der Quellcode mit diesem Artikel enthält außerdem ein Demo -Webanwendungsprojekt, das die DynamicicAntPlicationsSQLMemberShipProvider, die neuen Login -Steuerelemente, unser benutzerdefiniertes HTTP -Modul ... usw. demonstriert.
Abbildung 2 - Visual Studio -Lösung
Um diese Demo -Bewerbung auszuführen, befolgen Sie bitte die folgenden Schritte:
Nach diesen Schritten sollten Sie bereit sein, die Demo -Webanwendung auszuführen. Sie haben eine Datenbank erstellt, die zwei Anwendungen und einen Benutzer für jede Anwendung enthält.
Wenn Sie die Webanwendung starten, können Sie sich bei jeder Anwendung anmelden, indem Sie den Anwendungsnamen (Domain) gefolgt von einem Backslash und dem Benutzernamen specyfing. Natürlich ist auch das Passwort des Benutzers erforderlich.
Die von uns erstellten Anmeldesteuerungen kümmern sich um den Rest und stellen Sie sicher, dass Sie im richtigen Anwendungskontext arbeiten. Alle nachfolgenden Anrufe mit der ASP.NET -Mitgliedschaftsbibliothek auslösen den benutzerdefinierten Mitgliedschaftsanbieter so, dass der richtige Anwendungsname zurückgibt, wodurch diese Aufrufe im korrekten Anwendungskontext funktionieren.
Bemerkung : Die Web.config -Datei der Demo -Webanwendung enthält Kommentare, die alles angeben, was Sie tun müssen, um die Anwendung ordnungsgemäß einzurichten. Achten Sie darauf, es zu überprüfen.
Dieser Artikel hat Ihnen gezeigt, wie Sie das ASP.NET -Mitgliedschaftssystem nutzen können, um eine Portalanwendung zu erstellen, mit der Benutzer sich bei einer von vielen virtuellen Anwendungen anmelden können.
Der erste Schlüssel zur Erkenntnis ist, einen benutzerdefinierten Mitgliedschaftsanbieter zu erstellen, der sicherstellt, dass Sie im richtigen Anwendungskontext arbeiten, indem der Wert für die Anwendungsname -Eigenschaft von einem Speicherort abgerufen wird, der an eine individuelle Anforderung gebunden ist.
Durch das Erstellen einer benutzerdefinierten Anmeldung, die über die Standard -ASP.NET -Anmeldesteuerung abfällt, können wir feststellen, auf welche Anwendung der Benutzer zugreifen möchte.
Durch die Einschränkung dieser Informationen in einem verschlüsselten Cookie können wir die Anwendung automatisch identifizieren, auf die der Benutzer für jede seiner Anfragen zugreifen möchte.
