Freigeben über


Eine Übersicht über die Formularauthentifizierung (C#)

von Scott Mitchell

Hinweis

Da dieser Artikel geschrieben wurde, werden die ASP.NET Mitgliedschaftsanbieter von ASP.NET Identity abgelöst. Es wird dringend empfohlen, Apps so zu aktualisieren, dass sie die ASP.NET Identity Platform anstelle der Mitgliedschaftsanbieter verwenden, die zu dem Zeitpunkt dieses Artikels vorgestellt wurden. ASP.NET Identity hat eine Reihe von Vorteilen gegenüber dem ASP.NET Mitgliedschaftssystem, darunter:

  • Bessere Leistung
  • Verbesserte Erweiterbarkeit und Testbarkeit
  • Unterstützung für OAuth, OpenID Connect und zweistufige Authentifizierung
  • Anspruchsbasierte Identitätsunterstützung
  • Bessere Interoperabilität mit ASP.Net Core

Code herunterladen oder PDF herunterladen

In diesem Lernprogramm werden wir uns von bloßer Diskussion bis hin zur Implementierung wenden; Insbesondere werden wir die Implementierung der Formularauthentifizierung untersuchen. Die Webanwendung, die wir in diesem Lernprogramm erstellen, wird weiterhin in nachfolgenden Lernprogrammen erstellt, da wir von der einfachen Formularauthentifizierung zu Mitgliedschaft und Rollen wechseln.

Weitere Informationen zu diesem Thema finden Sie in diesem Video: Verwenden der Standardformularauthentifizierung in ASP.NET.

Einleitung

Im vorherigen Lernprogramm haben wir die verschiedenen Authentifizierungs-, Autorisierungs- und Benutzerkontooptionen erläutert, die von ASP.NET bereitgestellt werden. In diesem Lernprogramm werden wir uns von bloßer Diskussion bis hin zur Implementierung wenden; Insbesondere werden wir die Implementierung der Formularauthentifizierung untersuchen. Die Webanwendung, die wir in diesem Lernprogramm erstellen, wird weiterhin in nachfolgenden Lernprogrammen erstellt, da wir von der einfachen Formularauthentifizierung zu Mitgliedschaft und Rollen wechseln.

Dieses Lernprogramm beginnt mit einem eingehenden Blick auf den Formularauthentifizierungsworkflow, ein Thema, das wir im vorherigen Lernprogramm behandelt haben. Danach erstellen wir eine ASP.NET-Website, um die Konzepte der Formularauthentifizierung zu demonstrieren. Als Nächstes konfigurieren wir die Website für die Verwendung der Formularauthentifizierung, erstellen eine einfache Anmeldeseite und erfahren, wie Sie im Code ermitteln, ob ein Benutzer authentifiziert ist, und wenn ja, den Benutzernamen, mit dem er angemeldet ist.

Das Verständnis des Formularauthentifizierungsworkflows, das Aktivieren in einer Webanwendung und das Erstellen der Anmelde- und Abmeldeseiten sind alle wichtigen Schritte beim Erstellen einer ASP.NET-Anwendung, die Benutzerkonten unterstützt und Benutzer über eine Webseite authentifiziert. Deshalb – und da diese Lernprogramme aufeinander aufbauen – würde ich Sie ermutigen, dieses Lernprogramm vollständig zu bearbeiten, bevor Sie mit dem nächsten fortfahren, auch wenn Sie bereits Erfahrung mit der Konfiguration der Formularauthentifizierung in früheren Projekten hatten.

Grundlegendes zum Formularauthentifizierungsworkflow

Wenn die ASP.NET Laufzeit eine Anforderung für eine ASP.NET Ressource verarbeitet, z. B. eine ASP.NET Seite oder ASP.NET Webdienst, löst die Anforderung während des Lebenszyklus eine Reihe von Ereignissen aus. Es gibt Ereignisse, die am Anfang und am Ende der Anforderung ausgelöst werden, die ausgelöst werden, wenn die Anforderung authentifiziert und autorisiert wird, ein Ereignis, das im Falle einer unbehandelten Ausnahme ausgelöst wird usw. Eine vollständige Auflistung der Ereignisse finden Sie unter den Ereignissen des HttpApplication-Objekts.

HTTP-Module sind verwaltete Klassen, deren Code als Reaktion auf ein bestimmtes Ereignis im Anforderungslebenszyklus ausgeführt wird. ASP.NET enthält eine Reihe von HTTP-Modulen, die wesentliche Aufgaben hinter den Kulissen ausführen. Zwei integrierte HTTP-Module, die für unsere Diskussion besonders relevant sind:

  • FormsAuthenticationModule – authentifiziert den Benutzer durch Prüfen des Formularauthentifizierungstickets, das in der Regel in der Cookiessammlung des Benutzers enthalten ist. Wenn kein Formularauthentifizierungsticket vorhanden ist, ist der Benutzer anonym.
  • UrlAuthorizationModule – bestimmt, ob der aktuelle Benutzer berechtigt ist, auf die angeforderte URL zuzugreifen. Dieses Modul bestimmt die Autorität, indem die in den Konfigurationsdateien der Anwendung angegebenen Autorisierungsregeln konsultiert werden. ASP.NET umfasst auch das FileAuthorizationModule, das die Berechtigungen überprüft, indem es die angeforderten Datei-ACLs konsultiert.

FormsAuthenticationModule versucht, den Benutzer zu authentifizieren, bevor UrlAuthorizationModule (und FileAuthorizationModule) ausgeführt werden. Wenn der Benutzer, der die Anforderung stellt, nicht für den Zugriff auf die angeforderte Ressource autorisiert ist, beendet das Autorisierungsmodul die Anforderung und gibt den STATUS "HTTP 401 Nicht autorisiert" zurück. In Windows-Authentifizierungsszenarien wird der HTTP 401-Status an den Browser zurückgegeben. Dieser Statuscode bewirkt, dass der Browser den Benutzer über ein modales Dialogfeld zur Eingabe seiner Anmeldeinformationen auffordert. Bei der Formularauthentifizierung wird der STATUS "HTTP 401 Nicht autorisiert" jedoch nie an den Browser gesendet, da das FormsAuthenticationModule diesen Status erkennt und ändert ihn so, dass er stattdessen an die Anmeldeseite umgeleitet wird (über einen HTTP 302-Umleitungsstatus ).

Die Verantwortung der Anmeldeseite besteht darin, zu bestimmen, ob die Anmeldeinformationen des Benutzers gültig sind, und wenn ja, ein Formularauthentifizierungsticket zu erstellen und den Benutzer zurück zur Seite zu leiten, die er besuchen wollte. Das Authentifizierungsticket ist in nachfolgenden Anfragen an die Webseiten der Website enthalten, die der FormsAuthenticationModule zur Identifizierung des Benutzers verwendet.

Der Formularauthentifizierungsworkflow

Abbildung 1: Der Formularauthentifizierungsworkflow

Erinnerung an das Authentifizierungsticket bei Seitenbesuchen

Nach der Anmeldung muss das Formularauthentifizierungsticket auf jeder Anforderung an den Webserver zurückgesendet werden, damit der Benutzer beim Durchsuchen der Website angemeldet bleibt. Dies wird in der Regel erreicht, indem das Authentifizierungsticket in der Cookies-Sammlung des Benutzers platziert wird. Cookies sind kleine Textdateien, die sich auf dem Computer des Benutzers befinden und in den HTTP-Headern auf jeder Anforderung an die Website übermittelt werden, die das Cookie erstellt hat. Sobald das Formularauthentifizierungsticket erstellt und in den Cookies des Browsers gespeichert wurde, sendet jeder nachfolgende Besuch auf dieser Website das Authentifizierungsticket zusammen mit der Anforderung, wodurch der Benutzer identifiziert wird.

Ein Aspekt der Cookies ist deren Ablauf, also das Datum und die Uhrzeit, zu der der Browser das Cookie verwirft. Wenn das Formularauthentifizierungscookies abläuft, kann der Benutzer nicht mehr authentifiziert werden und wird daher anonym. Wenn ein Benutzer ein öffentliches Terminal verwendet, ist es wahrscheinlich, dass sein Authentifizierungsticket abläuft, wenn er den Browser schließt. Bei einem Besuch von zu Hause aus möchte derselbe Benutzer jedoch möglicherweise, dass das Authentifizierungsticket über Browserneustarts erinnert wird, damit er sich nicht bei jedem Besuch der Website erneut anmelden muss. Diese Entscheidung wird häufig vom Benutzer in Form eines Kontrollkästchens "Mich merken" auf der Anmeldeseite getroffen. In Schritt 3 werden wir untersuchen, wie man auf der Anmeldeseite ein Kontrollkästchen 'Merken' implementiert. Im folgenden Tutorial werden die Timeouteinstellungen für das Authentifizierungsticket ausführlich behandelt.

Hinweis

Es ist möglich, dass der Zum Anmelden bei der Website verwendete Nutzer-Agent Cookies nicht unterstützt. In einem solchen Fall können ASP.NET cookieslose Formularauthentifizierungstickets verwenden. In diesem Modus wird das Authentifizierungsticket in die URL codiert. Wir werden uns ansehen, wann cookielose Authentifizierungstickets verwendet werden und wie sie im nächsten Lernprogramm erstellt und verwaltet werden.

Der Gültigkeitsbereich der Formularauthentifizierung

Der FormsAuthenticationModule verwaltete Code ist Teil der ASP.NET Laufzeit. Vor Version 7 des Iis-Webservers (Internet Information Services) von Microsoft gab es eine unterschiedliche Barriere zwischen der HTTP-Pipeline von IIS und der Pipeline der ASP.NET Laufzeit. Kurz gesagt, wird FormsAuthenticationModule in IIS 6 und früher nur ausgeführt, wenn eine Anforderung von IIS an die ASP.NET-Laufzeit delegiert wird. Standardmäßig verarbeitet IIS statische Inhalte selbst – wie HTML-Seiten und CSS- und Bilddateien – und übergibt anforderungen nur an die ASP.NET Laufzeit, wenn eine Seite mit der Erweiterung .aspx, ASMX oder ASHX angefordert wird.

IIS 7 ermöglicht jedoch integrierte IIS- und ASP.NET-Pipelines. Mit einigen Konfigurationseinstellungen können Sie IIS 7 so einrichten, dass das FormsAuthenticationModule für alle Anforderungen aufgerufen wird. Darüber hinaus können Sie mit IIS 7 URL-Autorisierungsregeln für Dateien beliebiger Art definieren. Weitere Informationen finden Sie unter "Änderungen zwischen IIS6 und IIS7-Sicherheit", "Ihre Webplattformsicherheit" und "Grundlegendes zur IIS7-URL-Autorisierung".

Long Story short, in Versionen vor IIS 7, können Sie nur die Formularauthentifizierung verwenden, um Ressourcen zu schützen, die von der ASP.NET Laufzeit behandelt werden. Ebenso werden URL-Autorisierungsregeln nur auf Ressourcen angewendet, die von der ASP.NET Laufzeit behandelt werden. Mit IIS 7 ist es jedoch möglich, formsAuthenticationModule und UrlAuthorizationModule in die HTTP-Pipeline von IIS zu integrieren, wodurch diese Funktionalität auf alle Anforderungen erweitert wird.

Schritt 1: Erstellen einer ASP.NET Website für diese Lernprogrammreihe

Um das größtmögliche Publikum zu erreichen, wird die ASP.NET Website, die wir in dieser Reihe erstellen, mit der kostenlosen Version von Microsoft Visual Studio 2008, Visual Web Developer 2008, erstellt. Wir implementieren den SqlMembershipProvider Benutzerspeicher in einer Microsoft SQL Server 2005 Express Edition-Datenbank . Wenn Sie Visual Studio 2005 oder eine andere Edition von Visual Studio 2008 oder SQL Server verwenden, machen Sie sich keine Sorgen – die Schritte sind nahezu identisch, und alle nicht trivialen Unterschiede werden hervorgehoben.

Hinweis

Die demo-Webanwendung, die in jedem Lernprogramm verwendet wird, ist als Download verfügbar. Diese herunterladbare Anwendung wurde mit Visual Web Developer 2008 für .NET Framework, Version 3.5, erstellt. Da die Anwendung auf .NET 3.5 ausgerichtet ist, enthält die Web.config Datei zusätzliche, 3.5-spezifische Konfigurationselemente. Kurz gesagt, wenn Sie auf Ihrem Computer noch kein .NET 3.5 installiert haben, funktioniert die herunterladbare Webanwendung nicht, ohne zuvor das 3.5-spezifische Markup aus Web.configzu entfernen.

Bevor wir die Formularauthentifizierung konfigurieren können, benötigen wir zuerst eine ASP.NET Website. Erstellen Sie zunächst eine neue dateisystembasierte ASP.NET Website. Starten Sie dazu Visual Web Developer, und wechseln Sie dann zum Menü "Datei", und wählen Sie "Neue Website" aus, und zeigen Sie das Dialogfeld "Neue Website" an. Wählen Sie die ASP.NET Websitevorlage aus, legen Sie die Dropdownliste "Speicherort" auf "Dateisystem" fest, wählen Sie einen Ordner aus, in dem die Website platziert werden soll, und legen Sie die Sprache auf C# fest. Dadurch wird eine neue Website mit einer Default.aspx ASP.NET Seite, einem App_Data Ordner und einer Web.config Datei erstellt.

Hinweis

Visual Studio unterstützt zwei Projektmanagementmodi: Websiteprojekte und Webanwendungsprojekte. Websiteprojekte verfügen nicht über eine Projektdatei, während Webanwendungsprojekte die Projektarchitektur in Visual Studio .NET 2002/2003 nachahmen – sie enthalten eine Projektdatei und kompilieren den Quellcode des Projekts in einer einzigen Assembly, die im Ordner "/bin" abgelegt wird. Visual Studio 2005 unterstützt anfänglich nur Websiteprojekte, obwohl das Webanwendungsprojektmodell mit Service Pack 1 wieder eingeführt wurde; Visual Studio 2008 bietet beide Projektmodelle. Die Editionen Visual Web Developer 2005 und 2008 unterstützen jedoch nur Websiteprojekte. Ich verwende das Website-Projektmodell. Wenn Sie stattdessen eine Nicht-Express-Edition verwenden und stattdessen das Webanwendungsprojektmodell verwenden möchten, können Sie dies tun, aber beachten Sie, dass es möglicherweise Unterschiede zwischen den auf Dem Bildschirm angezeigten Inhalten und den Schritten gibt, die Sie im Vergleich zu den in diesen Lernprogrammen gezeigten Screenshots und Anweisungen ausführen müssen.

Eine neue Datei erstellen System-Based Webseite

Abbildung 2: Erstellen einer neuen Datei System-Based Website (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Hinzufügen einer Masterseite

Fügen Sie als Nächstes eine neue Master-Seite zur Website im Stammverzeichnis unter dem Namen "Site.master" hinzu. Gestaltungsvorlagen ermöglichen es einem Seitenentwickler, eine websiteweite Vorlage zu definieren, die auf ASP.NET Seiten angewendet werden kann. Der Hauptvorteil von Gestaltungsvorlagen besteht darin, dass die Gesamtdarstellung der Website an einem zentralen Ort definiert werden kann, wodurch es einfach ist, das Layout der Website zu aktualisieren oder zu optimieren.

Fügen Sie eine Masterseite mit dem Namen

Abbildung 3: Hinzufügen einer Master Page mit dem Namen "Site.master" zur Website (Zum Anzeigen des Bilds in voller Größe klicken)

Definieren Sie das globale Seitenlayout hier auf der Masterseite. Sie können die Entwurfsansicht verwenden und beliebige Layout- oder Websteuerelemente hinzufügen, oder Sie können das Markup manuell in der Quellansicht hinzufügen. Ich habe das Layout meiner Gestaltungsvorlage so strukturiert, dass das Layout in meiner Lernprogrammreihe " Arbeiten mit Daten" in ASP.NET 2.0 nachahmt wird (siehe Abbildung 4). Die Gestaltungsvorlage verwendet Cascading Stylesheets zum Positionieren und Formatvorlagen mit den CSS-Einstellungen, die in der Datei Style.css definiert sind (die im zugeordneten Download dieses Lernprogramms enthalten ist). Sie können zwar nicht aus dem unten gezeigten Markup erkennen, die CSS-Regeln werden jedoch so definiert, dass der Inhalt des Navigations-DIV <>absolut positioniert ist, sodass es links angezeigt wird und eine feste Breite von 200 Pixel aufweist.

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="Site.master.cs" Inherits="Site" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Forms Authentication, Authorization, and User Accounts</title>
    <link href="Styles.css" rel="stylesheet" type="text/css" />
</head>
<body>
    <div id="wrapper">
        <form id="form1" runat="server">
        
            <div id="header">
                <span class="title">User Account Tutorials</span>
            </div>
        
            <div id="content">
                <asp:contentplaceholder id="MainContent" runat="server">
                  <!-- Page-specific content will go here... -->
                </asp:contentplaceholder>
            </div>
            
            <div id="navigation">
                TODO: Menu will go here...
            </div>
        </form>
    </div>
</body>
</html>

Eine Gestaltungsvorlage definiert sowohl das statische Seitenlayout als auch die Bereiche, die von den ASP.NET Seiten bearbeitet werden können, die die Gestaltungsvorlage verwenden. Diese bearbeitbaren Inhaltsbereiche werden durch das ContentPlaceHolder Steuerelement angegeben, das im Div-Element des Inhalts <>angezeigt werden kann. Unsere Masterseite verfügt über ein einzelnes ContentPlaceHolder (MainContent), aber Masterseiten können mehrere ContentPlaceHolders haben.

Wenn das oben eingegebene Markup angezeigt wird, zeigt der Wechsel zur Entwurfsansicht das Layout der Gestaltungsvorlage an. Alle ASP.NET Seiten, die diese Gestaltungsvorlage verwenden, verfügen über dieses einheitliche Layout, mit der Möglichkeit, das Markup für den MainContent Bereich anzugeben.

Die Masterseite, wenn sie in der Entwurfsansicht betrachtet wird

Abbildung 4: Die Masterseite in der Entwurfsansicht (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Erstellen von Inhaltsseiten

Zu diesem Zeitpunkt haben wir eine Default.aspx-Seite auf unserer Website, aber sie verwendet nicht die Masterseite, die wir soeben erstellt haben. Obwohl es möglich ist, das deklarative Markup einer Webseite so zu bearbeiten, dass eine Gestaltungsvorlage verwendet wird, wenn die Seite noch keinen Inhalt enthält, ist es einfacher, die Seite einfach zu löschen und dem Projekt erneut hinzuzufügen, wobei die zu verwendende Gestaltungsvorlage angegeben wird. Löschen Sie daher zunächst Default.aspx aus dem Projekt.

Klicken Sie als Nächstes im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen, und wählen Sie aus, ein neues Webformular mit dem Namen Default.aspx hinzuzufügen. Aktivieren Sie dieses Mal das Kontrollkästchen "Masterseite auswählen" und wählen Sie die "Site.master"-Masterseite aus der Liste aus.

Neue Default.aspx-Seite hinzufügen und Masterseite auswählen

Abbildung 5: Hinzufügen einer neuen Default.aspx-Seite bei der Auswahl einer Masterseite (Klicken, um das Bild in voller Größe anzuzeigen)

Verwenden Sie die

Abbildung 6: Verwenden Sie die Masterseite "Site.master"

Hinweis

Wenn Sie das Webanwendungsprojektmodell verwenden, enthält das Dialogfeld "Neues Element hinzufügen" kein Kontrollkästchen "Masterseite auswählen". Stattdessen müssen Sie ein Element vom Typ "Webinhaltsformular" hinzufügen. Nachdem Sie die Option "Webinhaltsformular" ausgewählt und auf "Hinzufügen" geklickt haben, zeigt Visual Studio dasselbe Dialogfeld "Master auswählen" in Abbildung 6 an.

Das deklarative Markup der neuen Default.aspx-Seite enthält nur eine @Page-Direktive, die den Pfad zur Datei der Masterseite angibt, sowie ein Content-Steuerelement für den MainContent ContentPlaceHolder der Masterseite.

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
</asp:Content>

Lassen Sie Default.aspx vorerst leer. Später in diesem Lernprogramm werden wir darauf zurückkommen, um Inhalte hinzuzufügen.

Hinweis

Unsere Masterseite enthält einen Abschnitt für ein Menü oder eine andere Navigationsoberfläche. Wir werden eine solche Schnittstelle in einem zukünftigen Lernprogramm erstellen.

Schritt 2: Aktivieren der Formularauthentifizierung

Nachdem die ASP.NET Website erstellt wurde, besteht die nächste Aufgabe darin, die Formularauthentifizierung zu aktivieren. Die Authentifizierungskonfiguration der Anwendung wird über das <authentication> Element in Web.configangegeben. Das <authentication> Element enthält ein einzelnes Attribut namens Modus, das das von der Anwendung verwendete Authentifizierungsmodell angibt. Dieses Attribut kann einen der folgenden vier Werte aufweisen:

  • Windows – wie im vorherigen Lernprogramm erläutert, ist es für eine Anwendung, die Windows-Authentifizierung verwendet, die Verantwortung des Webservers, den Besucher zu authentifizieren, und dies erfolgt in der Regel über die Standard-, Digest- oder integrierte Windows-Authentifizierung.
  • Formulare– Benutzer werden über ein Formular auf einer Webseite authentifiziert.
  • Passport– Benutzer werden mithilfe des Passport-Netzwerks von Microsoft authentifiziert.
  • Keine – kein Authentifizierungsmodell wird verwendet; Alle Besucher sind anonym.

Standardmäßig verwenden ASP.NET Anwendungen die Windows-Authentifizierung. Um den Authentifizierungstyp in formularauthentifizierung zu ändern, müssen wir dann das Modus-Attribut des <authentication> Elements in Forms ändern.

Wenn Ihr Projekt noch keine Web.config Datei enthält, fügen Sie sie jetzt hinzu, indem Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen klicken, "Neues Element hinzufügen" auswählen und dann eine Webkonfigurationsdatei hinzufügen.

Wenn Ihr Projekt noch nicht Web.configenthält, fügen Sie es jetzt hinzu.

Abbildung 7: Wenn Ihr Projekt noch nicht Web.configenthält, fügen Sie es jetzt hinzu (Klicken Sie, um das Bild in voller Größe anzuzeigen)

Suchen Sie als Nächstes das <authentication> Element, und aktualisieren Sie es, um die Formularauthentifizierung zu verwenden. Nach dieser Änderung sollte das Markup Ihrer Web.config Datei wie folgt aussehen:

<configuration>
    <system.web>
        ... Unrelated configuration settings and comments removed for brevity ...
        <!--
            The <authentication> section enables configuration 
            of the security authentication mode used by 
            ASP.NET to identify an incoming user. 
        -->
        <authentication mode="Forms" />
    </system.web>
</configuration>

Hinweis

Da Web.config eine XML-Datei ist, ist die Schreibweise wichtig. Stellen Sie sicher, dass Sie das Modus-Attribut auf Forms mit einem Großbuchstaben "F" festlegen. Wenn Sie eine andere Groß-/Kleinschreibung verwenden, z. B. "Formulare", wird beim Besuch der Website über einen Browser ein Konfigurationsfehler angezeigt.

Das <authentication> Element kann optional ein <forms> untergeordnetes Element enthalten, das formularauthentifizierungsspezifische Einstellungen enthält. Jetzt verwenden wir einfach die Standardeinstellungen für die Formularauthentifizierung. Im nächsten Tutorial werden wir das <forms> untergeordnete Element ausführlicher untersuchen.

Schritt 3: Erstellen der Anmeldeseite

Um die Formularauthentifizierung zu unterstützen, benötigt unsere Website eine Anmeldeseite. Wie im Abschnitt "Grundlegendes zum Formularauthentifizierungsworkflow" beschrieben, leitet der FormsAuthenticationModule Benutzer automatisch zur Anmeldeseite um, wenn er versucht, auf eine Seite zuzugreifen, die nicht zum Anzeigen autorisiert ist. Es gibt auch ASP.NET Websteuerelemente, die einen Link zur Anmeldeseite für anonyme Benutzer anzeigen. Dies wirft die Frage auf: "Was ist die URL der Anmeldeseite?"

Standardmäßig erwartet das Formularauthentifizierungssystem, dass die Anmeldeseite Login.aspx benannt und im Stammverzeichnis der Webanwendung platziert wird. Wenn Sie eine andere Anmeldeseiten-URL verwenden möchten, können Sie dies tun, indem Sie sie in Web.configangeben. Im folgenden Lernprogramm wird gezeigt, wie dies zu tun ist.

Die Anmeldeseite hat drei Zuständigkeiten:

  1. Stellen Sie eine Schnittstelle bereit, über die der Besucher seine Anmeldeinformationen eingeben kann.
  2. Ermitteln Sie, ob die übermittelten Anmeldeinformationen gültig sind.
  3. Melden Sie sich beim Benutzer an, indem Sie das Formularauthentifizierungsticket erstellen.

Erstellen der Benutzeroberfläche der Anmeldeseite

Beginnen wir mit der ersten Aufgabe. Fügen Sie eine neue ASP.NET Seite zum Stammverzeichnis der Website mit dem Namen Login.aspx hinzu, und ordnen Sie sie der Gestaltungsvorlage "Site.master" zu.

Hinzufügen einer neuen ASP.NET Seite mit dem Namen Login.aspx

Abbildung 8: Hinzufügen einer neuen ASP.NET Seite mit dem Namen Login.aspx (Klicken, um das Bild in voller Größe anzuzeigen)

Die typische Anmeldeseitenschnittstelle besteht aus zwei Textfelder – einem für den Namen des Benutzers, eines für sein Kennwort – und einer Schaltfläche zum Senden des Formulars. Websites enthalten häufig ein Kontrollkästchen "Mich merken", das, falls aktiviert, das resultierende Authentifizierungsticket über Browserneustarts hinweg beibehalten wird.

Fügen Sie zwei TextBox-Objekte zu Login.aspx hinzu, und legen Sie deren ID Eigenschaften auf "UserName" bzw. "Password" fest. Legen Sie auch die Eigenschaft des Kennworts TextMode auf "Password" fest. Fügen Sie als Nächstes ein CheckBox-Steuerelement hinzu, und legen Sie dessen ID Eigenschaft auf "RememberMe" und seine Text Eigenschaft auf "Remember Me" fest. Fügen Sie anschließend eine Schaltfläche namens LoginButton hinzu, deren Text Eigenschaft auf "Login" festgelegt ist. Fügen Sie schließlich ein Bezeichnungswebsteuerelement hinzu, und legen Sie dessen ID Eigenschaft auf InvalidCredentialsMessage fest, dessen Text Eigenschaft auf "Ihr Benutzername oder Kennwort ist ungültig. Versuchen Sie es bitte erneut.", setzen Sie die ForeColor Eigenschaft auf Rot und die Visible Eigenschaft auf Falsch.

An diesem Punkt sollte ihr Bildschirm ähnlich wie der Screenshot in Abbildung 9 aussehen, und die deklarative Syntax Ihrer Seite sollte wie folgt aussehen:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Login.aspx.cs" Inherits="Login" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
    <h1>
        Login</h1>
    <p>
        Username:
        <asp:TextBox ID="UserName" runat="server"></asp:TextBox></p>
    <p>
        Password:
        <asp:TextBox ID="Password" runat="server" TextMode="Password"></asp:TextBox></p>
    <p>
        <asp:CheckBox ID="RememberMe" runat="server" Text="Remember Me" /> </p>
    <p>
        <asp:Button ID="LoginButton" runat="server" Text="Login" OnClick="LoginButton_Click" /> </p>
    <p>
        <asp:Label ID="InvalidCredentialsMessage" runat="server" ForeColor="Red" Text="Your username or password is invalid. Please try again."
            Visible="False"></asp:Label> </p>
</asp:Content>

Die Anmeldeseite enthält zwei Textfelder, ein CheckBox, eine Schaltfläche und ein Label.

Abbildung 9: Die Anmeldeseite enthält zwei Textfelder, ein CheckBox-Element, eine Schaltfläche und eine Beschriftung (Klicken Sie, um das Bild in voller Größe anzuzeigen)

Erstellen Sie schließlich einen Ereignishandler für das Click-Ereignis von LoginButton. Doppelklicken Sie im Designer einfach auf den Button, um diesen Ereignishandler zu erstellen.

Ermitteln, ob die angegebenen Anmeldeinformationen gültig sind

Nun müssen wir Aufgabe 2 im Click-Ereignishandler der Schaltfläche implementieren – bestimmen, ob die angegebenen Anmeldeinformationen gültig sind. Um dies zu tun, muss ein Benutzerspeicher vorhanden sein, der alle Anmeldeinformationen der Benutzer enthält, damit wir ermitteln können, ob die bereitgestellten Anmeldeinformationen mit bekannten Anmeldeinformationen übereinstimmen.

Vor ASP.NET 2.0 waren Entwickler dafür verantwortlich, sowohl ihre eigenen Benutzerspeicher zu implementieren als auch den Code zu schreiben, um die bereitgestellten Anmeldeinformationen für den Speicher zu überprüfen. Die meisten Entwickler implementieren den Benutzerspeicher in einer Datenbank, erstellen eine Tabelle namens "Benutzer" mit Spalten wie "Benutzername", "Kennwort", "E-Mail", "LastLoginDate" usw. Diese Tabelle hätte dann einen Datensatz pro Benutzerkonto. Das Überprüfen der von einem Benutzer angegebenen Anmeldeinformationen umfasst die Abfrage der Datenbank nach einem übereinstimmenden Benutzernamen und stellt dann sicher, dass das Kennwort in der Datenbank dem angegebenen Kennwort entspricht.

Mit ASP.NET 2.0 sollten Entwickler einen der Mitgliedschaftsanbieter verwenden, um den Benutzerspeicher zu verwalten. In dieser Lernprogrammreihe verwenden wir den SqlMembershipProvider, der eine SQL Server-Datenbank für den Benutzerspeicher verwendet. Bei Verwendung des SqlMembershipProviders müssen wir ein bestimmtes Datenbankschema implementieren, das die vom Anbieter erwarteten Tabellen, Ansichten und gespeicherten Prozeduren enthält. Im Lernprogramm zum Erstellen des Mitgliedschaftsschemas in SQL Server wird untersucht, wie dieses Schema implementiert wird. Wenn der Mitgliedschaftsanbieter vorhanden ist, ist die Überprüfung der Anmeldeinformationen des Benutzers so einfach wie das Aufrufen der ValidateUser(username, password)-Methode der Mitgliedschaftsklasse, die einen booleschen Wert zurückgibt, der angibt, ob die Gültigkeit der Kombination aus Benutzername und Kennwort angegeben wird. Da wir den Benutzerspeicher von SqlMembershipProvider noch nicht implementiert haben, können wir zurzeit die ValidateUser-Methode der Mitgliedschaftsklasse nicht verwenden.

Anstatt die Zeit zu nehmen, um unsere eigene benutzerdefinierte Benutzerdatenbanktabelle zu erstellen (die nach der Implementierung des SqlMembershipProviders veraltet wäre), müssen wir stattdessen die gültigen Anmeldeinformationen innerhalb der Anmeldeseite selbst hart codieren. Fügen Sie im Click-Ereignishandler von LoginButton den folgenden Code hinzu:

protected void LoginButton_Click(object sender, EventArgs e)
{
    // Three valid username/password pairs: Scott/password, Jisun/password, and Sam/password.
    string[] users = { "Scott", "Jisun", "Sam" };
    string[] passwords = { "password", "password", "password" };
    for (int i = 0; i < users.Length; i++)
    {
        bool validUsername = (string.Compare(UserName.Text, users[i], true) == 0);
        bool validPassword = (string.Compare(Password.Text, passwords[i], false) == 0);
        if (validUsername && validPassword)
        {
            // TODO: Log in the user...
            // TODO: Redirect them to the appropriate page
        }
    }
    // If we reach here, the user's credentials were invalid
    InvalidCredentialsMessage.Visible = true;
}

Wie Sie sehen können, gibt es drei gültige Benutzerkonten – Scott, Jisun und Sam – und alle drei haben dasselbe Kennwort ("Kennwort"). Der Code durchläuft die Benutzer- und Kennwortarrays, um eine gültige Übereinstimmung von Benutzername und Kennwort zu finden. Wenn sowohl der Benutzername als auch das Kennwort gültig sind, müssen wir den Benutzer anmelden und dann an die entsprechende Seite weiterleiten. Wenn die Anmeldeinformationen ungültig sind, wird die Bezeichnung "InvalidCredentialsMessage" angezeigt.

Wenn ein Benutzer gültige Anmeldeinformationen eingibt, habe ich erwähnt, dass er dann zur "entsprechenden Seite" umgeleitet wird. Was ist jedoch die entsprechende Seite? Denken Sie daran, dass der Benutzer, wenn er eine Seite besucht, die nicht zum Anzeigen autorisiert ist, die FormsAuthenticationModule diese automatisch an die Anmeldeseite weiterleitet. Dabei enthält sie die angeforderte URL in der Abfragezeichenfolge über den ReturnUrl-Parameter. Das heißt, wenn ein Benutzer versucht hat, ProtectedPage.aspx zu besuchen, und er nicht berechtigt war, dies zu tun, würde das FormsAuthenticationModule sie umleiten zu:

Login.aspx? ReturnUrl=ProtectedPage.aspx

Nach der erfolgreichen Anmeldung sollte der Benutzer zurück zu ProtectedPage.aspx umgeleitet werden. Alternativ können Benutzer die Anmeldeseite auf eigenem Willen besuchen. In diesem Fall sollte der Benutzer nach der Anmeldung an die Default.aspx-Seite des Stammordners gesendet werden.

Anmelden beim Benutzer

Vorausgesetzt, dass die angegebenen Anmeldeinformationen gültig sind, müssen wir ein Formularauthentifizierungsticket erstellen, wodurch sich der Benutzer bei der Website anmeldet. Die FormsAuthentication-Klasse im System.Web.Security-Namespace stellt verschiedene Methoden zum Anmelden und Abmelden von Benutzern über das Formularauthentifizierungssystem bereit. Während es mehrere Methoden in der FormsAuthentication-Klasse gibt, sind die drei, die wir an dieser Stelle interessieren:

  • GetAuthCookie(Benutzername, persistCookie) – erstellt ein Formularauthentifizierungsticket für den angegebenen Namensbenutzernamen. Als Nächstes erstellt und gibt diese Methode ein HttpCookie-Objekt zurück, das den Inhalt des Authentifizierungstickets enthält. Wenn persistCookie true ist, wird ein persistentes Cookie erstellt.
  • SetAuthCookie(username, persistCookie) – ruft die GetAuthCookie(username, persistCookie)-Methode auf, um das Formularauthentifizierungscookie zu generieren. Diese Methode fügt dann das von GetAuthCookie zurückgegebene Cookie zur Cookies-Sammlung hinzu (vorausgesetzt, die cookiesbasierte Formularauthentifizierung wird verwendet; andernfalls ruft diese Methode eine interne Klasse auf, die die Cookieless-Ticketlogik verarbeitet).
  • RedirectFromLoginPage(username, persistCookie) – diese Methode ruft SetAuthCookie(username, persistCookie) auf und leitet den Benutzer dann an die entsprechende Seite weiter.

GetAuthCookie ist praktisch, wenn Sie das Authentifizierungsticket ändern müssen, bevor Sie das Cookie in die Cookies-Sammlung schreiben. SetAuthCookie ist nützlich, wenn Sie das Formularauthentifizierungsticket erstellen und der Cookies-Sammlung hinzufügen möchten, den Benutzer jedoch nicht zur entsprechenden Seite umleiten möchten. Vielleicht möchten Sie sie auf der Anmeldeseite beibehalten oder an eine alternative Seite senden.

Da wir uns beim Benutzer anmelden und auf die entsprechende Seite umleiten möchten, verwenden wir RedirectFromLoginPage. Aktualisieren Sie den Click-Ereignishandler von LoginButton, und ersetzen Sie die beiden kommentierten TODO-Zeilen durch die folgende Codezeile:

FormsAuthentication.RedirectFromLoginPage(Benutzername.Text, RememberMe.Checked);

Beim Erstellen des Formularauthentifizierungstickets verwenden wir die Text-Eigenschaft der UserName TextBox für den Benutzernamenparameter und den markierten Status des RememberMe CheckBox für den persistCookie-Parameter.

Um die Anmeldeseite zu testen, besuchen Sie sie in einem Browser. Beginnen Sie, indem Sie ungültige Anmeldeinformationen eingeben, z. B. einen Benutzernamen von "Nope" und ein Kennwort von "falsch". Wenn Sie auf die Schaltfläche "Anmelden" klicken, wird die Seite neu geladen, und die Nachricht "Ungültige Anmeldeinformationen" wird angezeigt.

Die Bezeichnung

Abbildung 10: Die Bezeichnung "InvalidCredentialsMessage" wird angezeigt, wenn Sie ungültige Anmeldeinformationen eingeben (Klicken Sie, um das Bild in voller Größe anzuzeigen)

Geben Sie als Nächstes gültige Anmeldeinformationen ein, und klicken Sie auf die Schaltfläche "Anmelden". Dieses Mal, wenn das Postback auftritt, wird ein Formularauthentifizierungsticket erstellt, und Sie werden automatisch zurück zu Default.aspx umgeleitet. An diesem Punkt haben Sie sich bei der Website angemeldet, obwohl es keine visuellen Hinweise gibt, um anzugeben, dass Sie derzeit angemeldet sind. In Schritt 4 wird gezeigt, wie programmgesteuert ermittelt wird, ob ein Benutzer angemeldet ist oder nicht, und wie der Benutzer identifiziert wird, der die Seite besucht.

Schritt 5 untersucht Techniken zum Abmelden eines Benutzers aus der Website.

Sichern der Anmeldeseite

Wenn der Benutzer seine Anmeldeinformationen eingibt und das Anmeldeseitenformular übermittelt, werden die Anmeldeinformationen – einschließlich ihres Kennworts – über das Internet an den Webserver in Nur-Text übertragen. Das bedeutet, dass jeder Hacker, der den Netzwerkdatenverkehr snifft, den Benutzernamen und das Kennwort sehen kann. Um dies zu verhindern, ist es wichtig, den Netzwerkdatenverkehr mithilfe von Secure Socket Layers (SSL) zu verschlüsseln. Dadurch wird sichergestellt, dass die Anmeldeinformationen (sowie das HTML-Markup der gesamten Seite) ab dem Zeitpunkt, an dem sie den Browser verlassen, verschlüsselt werden, bis sie vom Webserver empfangen werden.

Sofern Ihre Website keine vertraulichen Informationen enthält, müssen Sie nur SSL auf der Anmeldeseite und auf anderen Seiten verwenden, auf denen das Kennwort des Benutzers andernfalls über das Kabel als Nur-Text gesendet wird. Sie müssen sich keine Gedanken über das Sichern des Formularauthentifizierungsticket machen, da es standardmäßig sowohl verschlüsselt als auch digital signiert ist (um Manipulationen zu verhindern). Eine ausführlichere Diskussion über die Sicherheit von Formularauthentifizierungstickets wird im folgenden Tutorial behandelt.

Hinweis

Viele finanztechnische und medizinische Websites sind so konfiguriert, dass SSL auf allen Seiten verwendet wird, die für authentifizierte Benutzer zugänglich sind. Wenn Sie eine solche Website erstellen, können Sie das Formularauthentifizierungssystem so konfigurieren, dass das Formularauthentifizierungsticket nur über eine sichere Verbindung übertragen wird.

Schritt 4: Erkennen authentifizierter Besucher und Ermitteln ihrer Identität

An diesem Punkt haben wir die Formularauthentifizierung aktiviert und eine rudimentäre Anmeldeseite erstellt, aber wir müssen noch prüfen, wie wir bestimmen können, ob ein Benutzer authentifiziert oder anonym ist. In bestimmten Szenarien möchten wir möglicherweise unterschiedliche Daten oder Informationen anzeigen, je nachdem, ob ein authentifizierter oder anonymer Benutzer die Seite besucht. Darüber hinaus müssen wir häufig die Identität des authentifizierten Benutzers kennen.

Lassen Sie uns die vorhandene Default.aspx Seite erweitern, um diese Techniken zu veranschaulichen. Fügen Sie in Default.aspx zwei Panel-Steuerelemente hinzu, eine mit dem Namen AuthenticatedMessagePanel und eine andere namens AnonymousMessagePanel. Fügen Sie ein Bezeichnungssteuerelement namens WelcomeBackMessage im ersten Panel hinzu. Legen Sie im zweiten Panel ein HyperLink-Steuerelement hinzu, legen Sie dessen Texteigenschaft auf "Log In" und die NavigateUrl-Eigenschaft auf "~/Login.aspx" fest. An diesem Punkt sollte das deklarative Markup für Default.aspx wie folgt aussehen:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
    <asp:Panel runat="server" ID="AuthenticatedMessagePanel">
        <asp:Label runat="server" ID="WelcomeBackMessage"></asp:Label>
    </asp:Panel>
    
    <asp:Panel runat="Server" ID="AnonymousMessagePanel">
        <asp:HyperLink runat="server" ID="lnkLogin" Text="Log In" NavigateUrl="~/Login.aspx"></asp:HyperLink>
    </asp:Panel>
</asp:Content>

Wie Sie jetzt wahrscheinlich erraten haben, ist die Idee hier, nur das AuthenticatedMessagePanel für authentifizierte Besucher und nur das AnonymousMessagePanel für anonyme Besucher anzuzeigen. Dazu müssen wir die sichtbaren Eigenschaften dieser Panels festlegen, je nachdem, ob der Benutzer angemeldet ist oder nicht.

Die Request.IsAuthenticated-Eigenschaft gibt einen booleschen Wert zurück, der angibt, ob die Anforderung authentifiziert wurde. Geben Sie den folgenden Code in den Page_Load Ereignishandlercode ein:

protected void Page_Load(object sender, EventArgs e)
{
    if (Request.IsAuthenticated)
    {
        WelcomeBackMessage.Text = "Welcome back!";
    
        AuthenticatedMessagePanel.Visible = true;
        AnonymousMessagePanel.Visible = false;
    }
    else
    {
        AuthenticatedMessagePanel.Visible = false;
        AnonymousMessagePanel.Visible = true;
    }
}

Besuchen Sie mit diesem Code Default.aspx über einen Browser. Wenn Sie sich noch anmelden müssen, wird ein Link zur Anmeldeseite angezeigt (siehe Abbildung 11). Klicken Sie auf diesen Link, und melden Sie sich bei der Website an. Wie wir in Schritt 3 gesehen haben, werden Sie nach der Eingabe Ihrer Anmeldeinformationen an Default.aspx zurückgegeben, aber diesmal zeigt die Seite die Meldung "Willkommen zurück!" an (siehe Abbildung 12).

Bei anonymem Besuch wird ein Anmeldelink angezeigt.

Abbildung 11: Beim anonymen Besuch wird ein Anmeldelink angezeigt.

Authentifizierte Benutzer werden angezeigt

Abbildung 12: Authentifizierten Benutzern wird die Nachricht "Willkommen zurück!" angezeigt.

Wir können die aktuell angemeldete Benutzeridentität über die User-Eigenschaft des HttpContext-Objekts ermitteln. Das HttpContext -Objekt stellt Informationen zur aktuellen Anforderung dar und ist die Startseite für solche gängigen ASP.NET Objekte wie Antwort, Anforderung und Sitzung, unter anderem. Die User-Eigenschaft stellt den Sicherheitskontext der aktuellen HTTP-Anforderung dar und implementiert die IPrincipal-Schnittstelle.

Die User-Eigenschaft wird von FormsAuthenticationModule festgelegt. Wenn das FormsAuthenticationModule ein Formularauthentifizierungsticket in der eingehenden Anforderung findet, erstellt es ein neues GenericPrincipal-Objekt und weist es der User-Eigenschaft zu.

Prinzipalobjekte (z. B. GenericPrincipal) stellen Informationen zur Identität des Benutzers und zu den Rollen bereit, denen sie angehören. Die IPrincipal-Schnittstelle definiert zwei Member:

Wir können den Namen des aktuellen Besuchers mithilfe des folgenden Codes bestimmen:

Zeichenkette currentUsersName = User.Identity.Name;

Bei Verwendung der Formularauthentifizierung wird ein FormsIdentity-Objekt für die Identity-Eigenschaft von GenericPrincipal erstellt. Die FormsIdentity-Klasse gibt immer die Zeichenfolge "Forms" für die AuthenticationType-Eigenschaft und true für die IsAuthenticated-Eigenschaft zurück. Die Name-Eigenschaft gibt den Benutzernamen zurück, der beim Erstellen des Formularauthentifizierungstickets angegeben wurde. Zusätzlich zu diesen drei Eigenschaften umfasst FormsIdentity den Zugriff auf das zugrunde liegende Authentifizierungsticket über die Ticket-Eigenschaft. Die Ticket-Eigenschaft gibt ein Objekt vom Typ FormsAuthenticationTicket zurück, das Eigenschaften wie Expiration, IsPersistent, IssueDate, Name usw. enthält.

Der wichtige Punkt, der hier entfernt werden soll, ist, dass der in den Methoden FormsAuthentication.GetAuthCookie(username, persistCookie), FormsAuthentication.SetAuthCookie(username, persistCookie) und FormsAuthentication.RedirectFromLoginPage(username, persistCookie) angegebene Parameter derselbe Wert ist, der von User.Identity.Name zurückgegeben wird. Darüber hinaus ist das von diesen Methoden erstellte Authentifizierungsticket verfügbar, indem man User.Identity in ein FormsIdentity-Objekt umwandelt und dann auf die Ticket-Eigenschaft zugreift.

FormsIdentity ident = User.Identity as FormsIdentity;
FormsAuthenticationTicket authTicket = ident.Ticket;

Lassen Sie uns eine personalisiertere Nachricht in Default.aspx bereitstellen. Aktualisieren Sie den Page_Load Ereignishandler so, dass der Text-Eigenschaft der WelcomeBackMessage-Bezeichnung die Zeichenfolge "Willkommen zurück, Benutzername!" zugewiesen wird.

WelcomeBackMessage.Text = "Willkommen zurück, " + User.Identity.Name + "!";

Abbildung 13 zeigt die Auswirkung dieser Änderung (bei der Anmeldung als Benutzer Scott).

Die Willkommensnachricht enthält den Namen des aktuell angemeldeten Benutzers.

Abbildung 13: Die Willkommensnachricht enthält den Namen des aktuell angemeldeten Benutzers.

Verwenden der LoginView- und LoginName-Steuerelemente

Das Anzeigen unterschiedlicher Inhalte für authentifizierte und anonyme Benutzer ist eine häufige Anforderung; zeigt also den Namen des aktuell angemeldeten Benutzers an. Aus diesem Grund enthält ASP.NET zwei Websteuerelemente, die die gleiche Funktionalität wie in Abbildung 13 dargestellt bereitstellen, ohne jedoch eine einzelne Codezeile schreiben zu müssen.

Das LoginView-Steuerelement ist ein vorlagenbasiertes Websteuerelement, mit dem verschiedene Daten für authentifizierte und anonyme Benutzer leicht angezeigt werden können. Die LoginView enthält zwei vordefinierte Vorlagen:

  • AnonymousTemplate – jedes Markup, das dieser Vorlage hinzugefügt wird, wird nur anonymen Besuchern angezeigt.
  • LoggedInTemplate – das Markup dieser Vorlage wird nur für authentifizierte Benutzer angezeigt.

Fügen wir das LoginView-Steuerelement zur Masterseite „Site.master“ unserer Website hinzu. Anstatt nur das LoginView-Steuerelement hinzuzufügen, fügen wir nun sowohl ein neues ContentPlaceHolder-Steuerelement hinzu, als auch das LoginView-Steuerelement in diesem neuen ContentPlaceHolder-Steuerelement. Die Begründung für diese Entscheidung wird in Kürze offensichtlich.

Hinweis

Zusätzlich zur AnonymousTemplate und LoggedInTemplate kann das LoginView-Steuerelement rollenspezifische Vorlagen enthalten. Rollenspezifische Vorlagen zeigen Markup nur für Benutzer an, die zu einer bestimmten Rolle gehören. Wir werden die rollenbasierten Features des LoginView-Steuerelements in einem zukünftigen Lernprogramm untersuchen.

Fügen Sie in der Navigation zunächst einen ContentPlaceHolder namens LoginContent zur Masterseite innerhalb des Div-Elements hinzu. Sie können einfach ein ContentPlaceHolder-Steuerelement aus der Toolbox in die Quelltextansicht ziehen und das resultierende Markup direkt über dem Text "TODO: Menü wird hier eingefügt" platzieren.

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Fügen Sie als Nächstes ein LoginView-Steuerelement im LoginContent ContentPlaceHolder hinzu. Inhalte, die in die ContentPlaceHolder-Steuerelemente der Masterseite eingefügt werden, gelten als Standardinhalte für den ContentPlaceHolder. Das heißt, ASP.NET Seiten, die diese Gestaltungsvorlage verwenden, können ihren eigenen Inhalt für jeden ContentPlaceHolder angeben oder den Standardinhalt der Gestaltungsvorlage verwenden.

Die LoginView- und andere anmeldebezogene Steuerelemente befinden sich auf der Registerkarte "Anmeldung" der Toolbox.

Das LoginView-Steuerelement in der Toolbox

Abbildung 14: Das LoginView-Steuerelement in der Toolbox

Fügen Sie als Nächstes zwei <br/> elemente unmittelbar nach dem LoginView-Steuerelement hinzu, aber noch innerhalb des ContentPlaceHolder. An diesem Punkt sollte das Markup des Navigations-div-Elements <> wie folgt aussehen:

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
        </asp:LoginView>
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Die Vorlagen von LoginView können aus dem Designer oder dem deklarativen Markup definiert werden. Erweitern Sie aus dem Designer von Visual Studio das Smarttag von LoginView, das die konfigurierten Vorlagen in einer Dropdownliste auflistet. Geben Sie den Text "Hello, stranger" in the AnonymousTemplate ein; Fügen Sie als Nächstes ein HyperLink-Steuerelement hinzu, und legen Sie dessen Text- und NavigateUrl-Eigenschaften auf "Log In" bzw. "~/Login.aspx" fest.

Wechseln Sie nach dem Konfigurieren der AnonymousTemplate zu "LoggedInTemplate", und geben Sie den Text "Willkommen zurück, " ein. Ziehen Sie dann ein LoginName-Steuerelement aus der Toolbox in die LoggedInTemplate, und platzieren Sie es unmittelbar hinter dem Text "Willkommen zurück". Das LoginName-Steuerelement zeigt, wie der Name schon sagt, den Namen des aktuell angemeldeten Benutzers an. Intern gibt das LoginName-Steuerelement einfach die User.Identity.Name-Eigenschaft aus.

Nachdem Sie diese Ergänzungen zu den LoginView-Vorlagen vorgenommen haben, sollte das Markup ähnlich wie folgt aussehen:

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
            <LoggedInTemplate>
                Welcome back,
                <asp:LoginName ID="LoginName1" runat="server" />.
            </LoggedInTemplate>
            <AnonymousTemplate>
                Hello, stranger.
                <asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
            </AnonymousTemplate>
        </asp:LoginView>
        
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Mit dieser Ergänzung zur Gestaltungsvorlage "Site.master" zeigt jede Seite auf unserer Website eine andere Meldung an, je nachdem, ob der Benutzer authentifiziert ist. Abbildung 15 zeigt die Default.aspx Seite, wenn sie von Benutzer Jisun über einen Browser besucht wird. Die Nachricht "Willkommen zurück, Jisun" wird zweimal wiederholt: einmal im Navigationsbereich der Gestaltungsvorlage auf der linken Seite (über das LoginView-Steuerelement, das wir gerade hinzugefügt haben) und einmal im Inhaltsbereich des Default.aspx (über Panelsteuerelemente und programmgesteuerte Logik).

Das LoginView-Steuerelement wird angezeigt

Abbildung 15: Das LoginView-Steuerelement zeigt "Willkommen zurück, Jisun" an.

Da wir die LoginView zur Gestaltungsvorlage hinzugefügt haben, kann sie auf jeder Seite auf unserer Website angezeigt werden. Es kann jedoch Webseiten geben, auf denen diese Meldung nicht angezeigt werden soll. Eine solche Seite ist die Anmeldeseite, da ein Link zur Anmeldeseite dort fehl am Platz erscheint. Da wir das LoginView-Steuerelement in einem ContentPlaceHolder auf der Masterseite platziert haben, können wir das Standard-Markup auf unserer Inhaltsseite überschreiben. Öffnen Sie Login.aspx, und wechseln Sie zum Designer. Da wir in Login.aspx kein Content control für den LoginContent ContentPlaceHolder in der Masterseite explizit definiert haben, wird das Standardmarkup der Masterseite für diesen ContentPlaceHolder auf der Anmeldeseite angezeigt. Sie können dies über den Designer sehen – der LoginContent ContentPlaceHolder zeigt das Standardmarkup (das LoginView-Steuerelement).

Die Anmeldeseite zeigt den Standardinhalt für den ContentPlaceHolder

Abbildung 16: Die Anmeldeseite zeigt den Standardinhalt für den LoginContent ContentPlaceHolder der Masterseite an (Klicken, um das Bild in voller Größe anzuzeigen)

Um das Standardmarkup für den LoginContent ContentPlaceHolder außer Kraft zu setzen, klicken Sie einfach mit der rechten Maustaste auf den Bereich im Designer, und wählen Sie im Kontextmenü die Option "Benutzerdefinierten Inhalt erstellen" aus. (Bei Verwendung von Visual Studio 2008 enthält der ContentPlaceHolder ein Smarttag, das bei Auswahl dieselbe Option bietet.) Dadurch wird dem Markup der Seite ein neues Inhaltssteuerelement hinzugefügt. Dadurch können wir benutzerdefinierte Inhalte für diese Seite definieren. Sie könnten hier eine benutzerdefinierte Nachricht hinzufügen, z. B. "Bitte melden Sie sich an...", lassen Sie uns aber einfach dieses Leerzeichen hinterlassen.

Hinweis

In Visual Studio 2005 erstellt das Erstellen benutzerdefinierter Inhalte ein leeres Inhaltssteuerelement auf der ASP.NET Seite. In Visual Studio 2008 wird beim Erstellen benutzerdefinierter Inhalte der Standardinhalt der Masterseite in das soeben erstellte Inhaltssteuerelement kopiert. Wenn Sie Visual Studio 2008 verwenden, stellen Sie sicher, dass, nachdem Sie das neue Inhaltssteuerelement erstellt haben, der von der Masterseite kopierte Inhalt gelöscht wird.

Abbildung 17 zeigt die Login.aspx Seite, die von einem Browser aufgerufen wird, nachdem sie diese Änderung vorgenommen haben. Beachten Sie, dass im linken Navigations-div< keine Nachricht "Hallo, Fremder" oder "Willkommen zurück, >" vorhanden ist, wie es bei einem Besuch von Default.aspx der Fall ist.

Die Anmeldeseite blendet das Markup des Standard-LoginContent-ContentPlaceHolder aus.

Abbildung 17: Die Anmeldeseite blendet das Markup des Standardmäßigen LoginContent ContentPlaceHolder aus (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Schritt 5: Abmelden

In Schritt 3 haben wir uns die Erstellung einer Anmeldeseite angesehen, um einen Benutzer bei der Website anzumelden, aber wir müssen noch sehen, wie ein Benutzer abgemeldet wird. Zusätzlich zu Methoden zum Anmelden eines Benutzers stellt die FormsAuthentication-Klasse auch eine SignOut-Methode bereit. Die SignOut-Methode zerstört einfach das Formularauthentifizierungsticket, wodurch der Benutzer von der Website abgemeldet wird.

Das Anbieten eines Abmeldelinks ist ein so gängiges Feature, das ASP.NET ein Steuerelement enthält, das speziell für das Abmelden eines Benutzers entwickelt wurde. Das LoginStatus-Steuerelement zeigt abhängig vom Authentifizierungsstatusstatus entweder ein "Login"-LinkButton- oder ein "Logout"-LinkButton an. Ein "Login"-LinkButton wird für anonyme Benutzer gerendert, während ein "Abmelden"-LinkButton für authentifizierte Benutzer angezeigt wird. Der Text für die LinkButtons "Login" und "Logout" kann über die LoginStatus-Eigenschaften "LoginText" und "LogoutText" konfiguriert werden.

Durch Klicken auf das LinkButton -Element "Anmelden" wird ein Postback verursacht, von dem eine Umleitung an die Anmeldeseite ausgegeben wird. Durch Klicken auf das "Abmelden"-LinkButton wird das LoginStatus-Steuerelement die FormsAuthentication.SignOff-Methode aufrufen und dann den Benutzer zu einer Seite umleiten. Die Seite, zu der der abgemeldete Benutzer umgeleitet wird, hängt von der LogoutAction-Eigenschaft ab, die einem der drei folgenden Werte zugewiesen werden kann:

  • Aktualisieren – Standard; leitet den Benutzer zu der Seite weiter, die er gerade besucht hat. Wenn die Seite, die sie gerade besucht haben, anonyme Benutzer nicht zulässt, leitet formsAuthenticationModule den Benutzer automatisch an die Anmeldeseite weiter.

Sie können neugierig sein, warum hier eine Umleitung durchgeführt wird. Wenn der Benutzer auf derselben Seite bleiben möchte, warum die explizite Umleitung erforderlich ist? Der Grund dafür ist, dass der Benutzer beim Klicken auf das LinkButton-Element "Abmelden" weiterhin das Formularauthentifizierungsticket in seiner Cookies-Sammlung hat. Folglich ist die Postbackanforderung eine authentifizierte Anforderung. Das LoginStatus-Steuerelement ruft die SignOut-Methode auf, aber das geschieht, nachdem das FormsAuthenticationModule den Benutzer authentifiziert hat. Daher bewirkt eine explizite Umleitung, dass der Browser die Seite erneut anfordert. Wenn der Browser die Seite erneut anfordert, wurde das Formularauthentifizierungsticket entfernt und daher ist die eingehende Anforderung anonym.

  • Umleitung – der Benutzer wird an die URL umgeleitet, die durch die LogoutPageUrl-Eigenschaft von LoginStatus angegeben wurde.
  • RedirectToLoginPage – der Benutzer wird auf die Anmeldeseite umgeleitet.

Fügen wir der Masterseite ein LoginStatus-Steuerelement hinzu, und konfigurieren wir es so, dass es die Option "Umleitung" verwendet, um den Benutzer an eine Seite zu senden, die eine Meldung anzeigt, die bestätigt, dass der Benutzer abgemeldet wurde. Erstellen Sie zunächst eine Seite im Stammverzeichnis namens Logout.aspx. Vergessen Sie nicht, diese Seite der Gestaltungsvorlage "Site.master" zuzuordnen. Geben Sie als Nächstes eine Nachricht im Markup der Seite ein, die dem Benutzer erklärt, dass er abgemeldet wurde.

Kehren Sie als Nächstes zur Masterseite "Site.master" zurück und fügen Sie ein LoginStatus-Steuerelement unter der LoginView im LoginContent ContentPlaceHolder hinzu. Legen Sie die LogoutAction-Eigenschaft des LoginStatus-Steuerelements auf "Redirect" und dessen LogoutPageUrl-Eigenschaft auf "~/Logout.aspx" fest.

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
            <LoggedInTemplate>
                Welcome back,
                <asp:LoginName ID="LoginName1" runat="server" />.
            </LoggedInTemplate>
            <AnonymousTemplate>
                Hello, stranger.
                <asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
            </AnonymousTemplate>
        </asp:LoginView>
        <br />
        <asp:LoginStatus ID="LoginStatus1" runat="server" LogoutAction="Redirect" LogoutPageUrl="~/Logout.aspx" />
        
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Da sich der LoginStatus außerhalb des LoginView-Steuerelements befindet, wird er sowohl für anonyme als auch für authentifizierte Benutzer angezeigt, aber das ist OK, da der LoginStatus ordnungsgemäß ein "Login" oder "Logout" LinkButton anzeigt. Durch das Hinzufügen des LoginStatus-Steuerelements wird der HyperLink "Log In" im AnonymousTemplate überflüssig, daher sollte er entfernt werden.

Abbildung 18 zeigt Default.aspx, wenn Jisun die Seite besucht. Beachten Sie, dass in der linken Spalte die Meldung "Willkommen zurück, Jisun" zusammen mit einem Link zum Abmelden angezeigt wird. Wenn Sie auf das Abmelden klicken, bewirkt LinkButton einen Postback, signiert Jisun aus dem System und leitet sie dann zu Logout.aspx um. Wie in Abbildung 19 gezeigt, ist Jisun bereits anonym, wenn sie Logout.aspx erreicht, da sie sich schon abgemeldet hat. Folglich zeigt die linke Spalte den Text "Willkommen, Fremder" und einen Link zur Anmeldeseite an.

Default.aspx Shows

Abbildung 18: Default.aspx zeigt "Willkommen zurück, Jisun" zusammen mit einem "Abmelden" LinkButton (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Logout.aspx Shows

Abbildung 19: Logout.aspx zeigt "Willkommen, Fremder" zusammen mit einem "Login"-LinkButton (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Hinweis

Ich empfehle Ihnen, die Seite Logout.aspx anzupassen, um den LoginContent ContentPlaceHolder der Masterseite auszublenden (wie wir es in Schritt 4 für Login.aspx getan haben). Der Grund dafür ist, dass der vom LoginStatus-Steuerelement gerenderte LinkButton (der unter "Hallo, Fremder") den Benutzer an die Anmeldeseite sendet, indem er die aktuelle URL im ReturnUrl-Abfragezeichenfolgenparameter übergibt. Kurz gesagt, wenn ein Benutzer, der sich abgemeldet hat, auf das "Login"-LinkButton von LoginStatus klickt und sich dann anmeldet, wird er zurück zu Logout.aspx umgeleitet, was den Benutzer leicht verwechseln kann.

Zusammenfassung

In diesem Lernprogramm haben wir mit einer Prüfung des Formularauthentifizierungsworkflows begonnen und dann die Implementierung der Formularauthentifizierung in einer ASP.NET Anwendung durchgeführt. Die Formularauthentifizierung wird von FormsAuthenticationModule unterstützt, das zwei Zuständigkeiten hat: Identifizieren von Benutzern basierend auf ihrem Formularauthentifizierungsticket und Umleiten nicht autorisierter Benutzer an die Anmeldeseite.

Die FormsAuthentication-Klasse von .NET Framework enthält Methoden zum Erstellen, Überprüfen und Entfernen von Formularauthentifizierungstickets. Die Request.IsAuthenticated-Eigenschaft und das User-Objekt bieten zusätzliche programmgesteuerte Unterstützung für die Ermittlung, ob eine Anforderung authentifiziert ist, und Informationen zur Identität des Benutzers. Es gibt auch die Steuerelemente LoginView, LoginStatus und LoginName Web, die Entwicklern eine schnelle, codefreie Möglichkeit zum Ausführen vieler gängiger Anmeldeaufgaben bieten. Wir werden diese und andere anmeldebezogene Websteuerelemente in zukünftigen Lernprogrammen genauer untersuchen.

Dieses Lernprogramm bietet eine cursorische Übersicht über die Formularauthentifizierung. Wir haben die sortierten Konfigurationsoptionen nicht untersucht, wie cookielose Formularauthentifizierungstickets funktionieren, oder wir haben untersucht, wie ASP.NET den Inhalt des Formularauthentifizierungstickets schützt.

Glückliche Programmierung!

Weitere Informationen

Weitere Informationen zu den in diesem Lernprogramm erläuterten Themen finden Sie in den folgenden Ressourcen:

Videoschulung zu Themen, die in diesem Lernprogramm enthalten sind

Zum Autor

Scott Mitchell, Autor von sieben ASP/ASP.NET Büchern und Gründer von 4GuysFromRolla.com, arbeitet seit 1998 mit Microsoft Web Technologies zusammen. Scott arbeitet als unabhängiger Berater, Trainer und Schriftsteller. Sein neuestes Buch ist Sams Teach Yourself ASP.NET 2.0 in 24 Stunden. Er kann bei mitchell@4GuysFromRolla.comerreicht werden.

Besonderer Dank an...

Diese Lernprogrammreihe wurde von vielen hilfreichen Prüfern überprüft. Lead Reviewer für dieses Lernprogramm war diese Lernprogrammreihe wurde von vielen hilfreichen Bearbeitern überprüft. Leitende Prüfer für dieses Lernprogramm sind Alicja Maziarz, John Suru und Teresa Murphy. Möchten Sie meine bevorstehenden MSDN-Artikel überprüfen? Wenn ja, schicken Sie mir eine Nachricht an mitchell@4GuysFromRolla.com.