En översikt över formulärautentisering (C#)

av Scott Mitchell

Anmärkning

Sedan den här artikeln skrevs har ASP.NET medlemskapsleverantörer ersatts av ASP.NET identitet. Vi rekommenderar starkt att du uppdaterar appar så att de använder ASP.NET identitetsplattformen i stället för de medlemskapsleverantörer som presenterades när den här artikeln skrevs. ASP.NET Identity har ett antal fördelar jämfört med ASP.NET medlemskapssystemet, inklusive :

• Bättre prestanda
• Förbättrad utökningsbarhet och testbarhet
• Stöd för OAuth, OpenID Connect och tvåfaktorsautentisering
• Stöd för anspråksbaserad identitet
• Bättre samverkan med ASP.Net Core

Ladda ned kod eller ladda ned PDF

I den här självstudien går vi från bara diskussion till implementering. I synnerhet kommer vi att titta på implementering av formulärautentisering. Webbprogrammet som vi börjar skapa i den här självstudien fortsätter att byggas på i efterföljande självstudier, när vi går från enkel formulärautentisering till medlemskap och roller.

Mer information om det här avsnittet finns i den här videon: Använda grundläggande formulärautentisering i ASP.NET.

Inledning

I föregående självstudie beskrev vi de olika alternativen för autentisering, auktorisering och användarkonto som tillhandahålls av ASP.NET. I den här självstudien går vi från bara diskussion till implementering. I synnerhet kommer vi att titta på implementering av formulärautentisering. Webbprogrammet som vi börjar skapa i den här självstudien fortsätter att byggas på i efterföljande självstudier, när vi går från enkel formulärautentisering till medlemskap och roller.

Den här självstudien börjar med en djupgående titt på arbetsflödet för formulärautentisering, ett ämne som vi berörde i föregående självstudie. Därefter skapar vi en ASP.NET webbplats för att demonstrera begreppen för formulärautentisering. Sedan konfigurerar vi webbplatsen så att den använder formulärautentisering, skapar en enkel inloggningssida och ser hur man i kod avgör om en användare autentiseras och i så fall användarnamnet som de loggade in med.

Att förstå arbetsflödet för formulärautentisering, aktivera det i ett webbprogram och skapa inloggnings- och utloggningssidor är alla viktiga steg för att skapa ett ASP.NET program som stöder användarkonton och autentiserar användare via en webbsida. På grund av detta – och eftersom de här självstudierna bygger på varandra – rekommenderar jag att du går igenom den här självstudien i sin helhet innan du går vidare till nästa, även om du redan har erfarenhet av att konfigurera formulärautentisering i tidigare projekt.

Förstå arbetsflödet för formulärautentisering

När ASP.NET-körningen bearbetar en begäran om en ASP.NET resurs, till exempel en ASP.NET-sida eller ASP.NET webbtjänst, genererar begäran ett antal händelser under livscykeln. Det finns händelser som uppkommer i början och slutet av begäran, händelser som görs när begäran autentiseras och auktoriseras, en händelse som uppkommer i händelse av ett ohanterat undantag och så vidare. En fullständig lista över händelserna finns i HttpApplication-objektets händelser.

HTTP-moduler är hanterade klasser vars kod körs som svar på en viss händelse i begärandelivscykeln. ASP.NET levereras med ett antal HTTP-moduler som utför viktiga uppgifter bakom kulisserna. Två inbyggda HTTP-moduler som är särskilt relevanta för vår diskussion är:

• FormsAuthenticationModule – autentiserar användaren genom att inspektera formulärautentiseringsbiljetten, som vanligtvis ingår i användarens cookiessamling. Om det inte finns någon formulärautentiseringsbegäran är användaren anonym.
• UrlAuthorizationModule – avgör om den aktuella användaren har behörighet att komma åt den begärda URL:en. Den här modulen bestämmer behörigheten genom att konsultera de auktoriseringsregler som anges i applikationens konfigurationsfiler. ASP.NET innehåller även mekanismen FileAuthorizationModule som bestämmer behörighet genom att konsultera de begärda fil-ACL:erna.

FormsAuthenticationModule försöker att autentisera användaren innan UrlAuthorizationModule (och FileAuthorizationModule) körs. Om användaren som gör begäran inte har behörighet att komma åt den begärda resursen avslutar auktoriseringsmodulen begäran och returnerar statusen HTTP 401 Obehörig . I Windows-autentiseringsscenarier returneras HTTP 401-statusen till webbläsaren. Den här statuskoden gör att webbläsaren uppmanar användaren att ange sina autentiseringsuppgifter via en modal dialogruta. Med formulärautentisering skickas dock inte HTTP 401-obehörig status till webbläsaren eftersom FormsAuthenticationModule identifierar den här statusen och ändrar den för att omdirigera användaren till inloggningssidan i stället (via http 302-omdirigeringsstatus ).

Inloggningssidans ansvar är att avgöra om användarens autentiseringsuppgifter är giltiga och i så fall skapa ett formulärautentiseringsärende och omdirigera användaren tillbaka till den sida som användaren försökte besöka. Autentiseringsbiljetten ingår i efterföljande begäranden till sidorna på webbplatsen, som FormsAuthenticationModule använder för att identifiera användaren.

Bild 1: Arbetsflödet för formulärautentisering

Komma ihåg autentiseringsbiljetten för sidbesök

När du har loggat in måste formulärautentiseringsbiljetten skickas tillbaka till webbservern för varje begäran så att användaren förblir inloggad när de bläddrar på webbplatsen. Detta görs vanligtvis genom att placera autentiseringsbiljetten i användarens cookiessamling. Cookies är små textfiler som finns på användarens dator och överförs i HTTP-huvudena på varje begäran till webbplatsen som skapade cookien. När formulärautentiseringsbiljetten har skapats och lagrats i webbläsarens cookies skickar därför varje efterföljande besök på webbplatsen autentiseringsbiljetten tillsammans med begäran, vilket identifierar användaren.

En aspekt av cookies är deras upphörande, vilket är det datum och den tid då webbläsaren tar bort cookien. När formulärautentiseringscookien upphör att gälla kan användaren inte längre autentiseras och därför bli anonym. När en användare besöker från en offentlig terminal är chansen stor att de vill att deras autentiseringsbiljett ska upphöra att gälla när de stänger webbläsaren. När du besöker hemifrån kanske samma användare vill att autentiseringsbiljetten ska kommas ihåg i webbläsarens omstarter så att de inte behöver logga in igen varje gång de besöker webbplatsen. Det här beslutet fattas ofta av användaren i form av kryssrutan "Kom ihåg mig" på inloggningssidan. I steg 3 undersöker vi hur du implementerar kryssrutan "Kom ihåg mig" på inloggningssidan. I följande handledning behandlas inställningarna för tidsgränsen för autentiseringsbiljetten i detalj.

Anmärkning

Det är möjligt att användaragenten som används för att logga in på webbplatsen kanske inte stöder cookies. I sådana fall kan ASP.NET använda autentiseringstokens för formulär utan cookies. I det här läget kodas autentiseringsbiljetten till URL:en. Vi tittar på när cookielösa autentiseringsbiljetter används och hur de skapas och hanteras i nästa självstudie.

Omfånget för formulärautentisering

FormsAuthenticationModule är hanterad kod som är en del av ASP.NET-körningen. Före version 7 av Microsofts IIS-webbserver (Internet Information Services) fanns det en tydlig barriär mellan IIS HTTP-pipeline och pipelinen för ASP.NET körning. Kortfattat, i IIS 6 och tidigare körs den FormsAuthenticationModule endast när en begäran delegeras från IIS till ASP.NET-körtiden. Som standard bearbetar IIS själva statiskt innehåll , till exempel HTML-sidor och CSS- och bildfiler, och lämnar endast förfrågningar till ASP.NET körning när en sida med ett tillägg av .aspx, .asmx eller .ashx begärs.

IIS 7 tillåter dock integrerade IIS- och ASP.NET pipelines. Med några konfigurationsinställningar kan du konfigurera IIS 7 för att anropa FormsAuthenticationModule för alla begäranden. Med IIS 7 kan du dessutom definiera URL-auktoriseringsregler för filer av valfri typ. Mer information finns i Ändringar mellan IIS6- och IIS7-säkerhet, Din webbplattformssäkerhet och Förstå IIS7-URL-auktorisering.

Lång historia kort, i versioner före IIS 7, kan du bara använda formulärautentisering för att skydda resurser som hanteras av ASP.NET körning. På samma sätt tillämpas regler för URL-auktorisering endast på resurser som hanteras av ASP.NET-körningen. Men med IIS 7 är det möjligt att integrera FormsAuthenticationModule och UrlAuthorizationModule i IIS HTTP-pipeline, vilket utökar den här funktionen till alla begäranden.

Steg 1: Skapa en ASP.NET webbplats för den här självstudieserien

För att nå ut till bredast möjliga målgrupp skapas den ASP.NET webbplats som vi skapar i hela serien med Microsofts kostnadsfria version av Visual Studio 2008, Visual Web Developer 2008. Vi implementerar användararkivet SqlMembershipProvider i en Microsoft SQL Server 2005 Express Edition-databas . Om du använder Visual Studio 2005 eller en annan version av Visual Studio 2008 eller SQL Server, oroa dig inte – stegen blir nästan identiska och eventuella icke-triviala skillnader kommer att påpekas.

Anmärkning

Demowebbapplikationen som används i varje handledning finns tillgänglig som nedladdning. Det här nedladdningsbara programmet skapades med Visual Web Developer 2008 som mål för .NET Framework version 3.5. Eftersom programmet är avsett för .NET 3.5 innehåller dess Web.config-fil ytterligare 3,5-specifika konfigurationselement. Lång historia kort, om du ännu inte har installerat .NET 3.5 på datorn kommer det nedladdningsbara webbprogrammet inte att fungera utan att först ta bort den 3,5-specifika markering från Web.config.

Innan vi kan konfigurera formulärautentisering behöver vi först en ASP.NET webbplats. Börja med att skapa en ny filsystembaserad ASP.NET webbplats. Det gör du genom att starta Visual Web Developer och sedan gå till menyn Arkiv och välja Ny webbplats. Dialogrutan Ny webbplats visas. Välj mallen ASP.NET webbplats, ange listrutan Plats till Filsystem, välj en mapp för att placera webbplatsen och ange språket till C#. Då skapas en ny webbplats med en Default.aspx ASP.NET sida, en App_Data-mapp och en Web.config fil.

Anmärkning

Visual Studio stöder två lägen för projekthantering: Webbplatsprojekt och webbprogramprojekt. Web Site Projects saknar en projektfil, medan webbprogramprojekt efterliknar projektarkitekturen i Visual Studio .NET 2002/2003 – de innehåller en projektfil och kompilerar projektets källkod till en enda sammansättning som placeras i mappen /bin. Visual Studio 2005 stödde ursprungligen endast webbplatsprojekt, även om projektmodellen för webbprogram återinfördes med Service Pack 1. Visual Studio 2008 erbjuder båda projektmodellerna. Utgåvorna Visual Web Developer 2005 och 2008 stöder dock endast webbplatsprojekt. Jag kommer att använda webbplatsens projektmodell. Om du använder en icke-Express-utgåva och vill använda projektmodellen för webbprogram i stället kan du göra det, men tänk på att det kan finnas vissa skillnader mellan det du ser på skärmen och de steg du måste vidta jämfört med de skärmdumpar som visas och instruktionerna i dessa självstudier.

Bild 2: Skapa en ny fil på System-Based-webbplatsen (Klicka för att visa bilden i full storlek)

Lägga till en huvudsida

Lägg sedan till en ny huvudsida på webbplatsen i rotkatalogen med namnet Site.master. Med huvudsidor kan en sidutvecklare definiera en webbplatsomfattande mall som kan tillämpas på ASP.NET sidor. Den största fördelen med huvudsidor är att webbplatsens övergripande utseende kan definieras på en enda plats, vilket gör det enkelt att uppdatera eller justera webbplatsens layout.

Bild 3: Lägg till en huvudsida med namnet Site.master på webbplatsen (Klicka om du vill visa en bild i full storlek)

Definiera sidlayouten för hela webbplatsen här på huvudsidan. Du kan använda designvyn och lägga till de layout- eller webbkontroller du behöver, eller så kan du manuellt lägga till markeringen för hand i källvyn. Jag strukturerade huvudsidans layout för att efterlikna layouten som används i självstudieserien Arbeta med data i ASP.NET 2.0 (se bild 4). Huvudsidan använder sammanhängande formatmallar för positionering och format med CSS-inställningarna som definierats i filen Style.css (som ingår i den här självstudiekursens associerade nedladdning). Även om du inte kan se från markeringarna nedan definieras CSS-reglerna så att innehållet i navigeringsdiven <>är helt positionerat så att det visas till vänster och har en fast bredd på 200 bildpunkter.

<%@ 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>

En huvudsida definierar både den statiska sidlayouten och de regioner som kan redigeras av de ASP.NET sidor som använder huvudsidan. Dessa områden som kan redigeras anges av ContentPlaceHolder kontrollen, som kan visas i innehållsdiven<>. Vår huvudsida har en enda ContentPlaceHolder (MainContent), men huvudsidans kan ha flera ContentPlaceHolders.

Med markeringen ovan visar växlingen till designvyn huvudsidans layout. Alla ASP.NET sidor som använder den här huvudsidan har den här enhetliga layouten, med möjlighet att ange markering för MainContent regionen.

Bild 4: Huvudsidan visas i designvyn (klicka om du vill visa en bild i full storlek)

Skapa innehållssidor

Nu har vi en Default.aspx sida på vår webbplats, men den använder inte huvudsidan som vi nyss skapade. Även om det är möjligt att ändra den deklarativa markeringen för en webbsida för att använda en huvudsida, är det enklare att bara ta bort sidan och lägga till den i projektet igen om sidan inte innehåller något innehåll ännu, och ange vilken huvudsida som ska användas. Börja därför med att ta bort Default.aspx från projektet.

Högerklicka sedan på projektnamnet i Solution Explorer och välj att lägga till ett nytt webbformulär med namnet Default.aspx. Den här gången markerar du kryssrutan "Välj huvudsida" och väljer huvudsidan Site.master i listan.

Bild 5: Lägg till en ny Default.aspx sida som väljer att välja en huvudsida (Klicka om du vill visa en bild i full storlek)

Bild 6: Använd huvudsidan site.master

Anmärkning

Om du använder projektmodellen för webbprogram innehåller dialogrutan Lägg till nytt objekt inte kryssrutan "Välj huvudsida". I stället måste du lägga till ett objekt av typen "Webbinnehållsformulär". När du har valt alternativet Webbinnehållsformulär och klickat på Lägg till visar Visual Studio samma dialogruta Välj en huvudruta som visas i bild 6.

Den nya Default.aspx sidans deklarativa markering innehåller bara ett @Page direktiv som anger sökvägen till huvudsidefilen och en innehållskontroll för huvudsidans MainContent ContentPlaceHolder.

<%@ 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>

Lämna Default.aspx tom för tillfället. Vi återkommer till den senare i den här handledningen för att lägga till innehåll.

Anmärkning

Vår huvudsida innehåller ett avsnitt för en meny eller något annat navigeringsgränssnitt. Vi kommer att skapa ett sådant gränssnitt i en framtida handledning.

Steg 2: Aktivera formulärautentisering

När ASP.NET webbplats har skapats är nästa uppgift att aktivera formulärautentisering. Programmets autentiseringskonfiguration anges via elementet<authentication> i Web.config. Elementet <authentication> innehåller ett enda attribut med namnet mode som anger den autentiseringsmodell som används av programmet. Det här attributet kan ha något av följande fyra värden:

• Windows – som beskrivs i föregående självstudie, när ett program använder Windows-autentisering är det webbserverns ansvar att autentisera besökaren, och detta görs vanligtvis via Grundläggande, Sammanfattad eller Integrerad Windows-autentisering.
• Formulär – användare autentiseras via ett formulär på en webbsida.
• Passport – användare autentiseras med Hjälp av Microsofts Passport-nätverk.
• Ingen – ingen autentiseringsmodell används. alla besökare är anonyma.

Som standard använder ASP.NET program Windows-autentisering. Om du vill ändra autentiseringstypen till formulärautentisering måste vi sedan ändra <authentication> elementets lägesattribut till Formulär.

Om projektet ännu inte innehåller en Web.config fil lägger du till en nu genom att högerklicka på projektnamnet i Solution Explorer, välja Lägg till nytt objekt och sedan lägga till en webbkonfigurationsfil.

Bild 7: Om projektet ännu inte innehåller Web.configlägger du till det nu (klicka om du vill visa en bild i full storlek)

Leta sedan upp elementet <authentication> och uppdatera det för att använda formulärautentisering. Efter den här ändringen bör Web.config-filens markering se ut ungefär så här:

<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>

Anmärkning

Eftersom Web.config är en XML-fil är hölje viktigt. Se till att du anger modeattributet till Formulär med versalt "F". Om du använder ett annat hölje, till exempel "formulär", får du ett konfigurationsfel när du besöker webbplatsen via en webbläsare.

Elementet <authentication> kan också innehålla ett <forms> underordnat element som innehåller autentiseringsspecifika inställningar för formulär. Nu ska vi bara använda standardinställningarna för formulärautentisering. Vi kommer att utforska det <forms> underordnade elementet mer detaljerat i nästa handledning.

Steg 3: Skapa inloggningssidan

För att kunna stödja formulärautentisering behöver vår webbplats en inloggningssida. Som beskrivs i avsnittet FormsAuthenticationModule "Förstå arbetsflödet för formulärautentisering" omdirigeras användaren automatiskt till inloggningssidan om de försöker komma åt en sida som de inte har behörighet att visa. Det finns också ASP.NET webbkontroller som visar en länk till inloggningssidan för anonyma användare. Detta väcker frågan "Vad är URL:en för inloggningssidan?"

Som standard förväntar sig formulärautentiseringssystemet att inloggningssidan namnges Login.aspx och placeras i webbprogrammets rotkatalog. Om du vill använda en annan url för inloggningssidan kan du göra det genom att ange den i Web.config. Vi kommer att se hur du gör detta i den efterföljande självstudien.

Inloggningssidan har tre ansvarsområden:

1. Ange ett gränssnitt som gör att besökaren kan ange sina autentiseringsuppgifter.
2. Kontrollera om de inskickade autentiseringsuppgifterna är giltiga.
3. Logga in användaren genom att skapa autentiseringstoken för formulär.

Skapa inloggningssidans användargränssnitt

Nu ska vi komma igång med den första uppgiften. Lägg till en ny ASP.NET sida i webbplatsens rotkatalog med namnet Login.aspx och associera den med huvudsidan site.master.

Bild 8: Lägg till en ny ASP.NET sida med namnet Login.aspx (Klicka om du vill visa en bild i full storlek)

Det typiska gränssnittet för inloggningssidan består av två textrutor – en för användarens namn, en för lösenordet – och en knapp för att skicka formuläret. Webbplatser innehåller ofta kryssrutan "Kom ihåg mig" som, om den är markerad, bevarar den resulterande autentiseringsbiljetten i webbläsarens omstarter.

Lägg till två textrutor i Login.aspx och ange deras ID egenskaper till Användarnamn respektive Lösenord. Ställ också in egenskapen TextMode till "Lösenord". Lägg sedan till en CheckBox-kontroll och ange dess ID egenskap till RememberMe och dess Text egenskap till "Kom ihåg mig". Därefter lägger du till en knapp med namnet LoginButton vars Text egenskap är inställd på "Login". Och slutligen lägger du till en etikettwebbkontroll och anger dess ID egenskap till InvalidCredentialsMessage, dess Text egenskap till "Ditt användarnamn eller lösenord är ogiltigt. Försök igen.", sätt dess ForeColor attribut till Red och dess Visible attribut till False.

Nu bör skärmen se ut ungefär som skärmbilden i bild 9, och sidans deklarativa syntax bör se ut så här:

<%@ 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>

Bild 9: Inloggningssidan innehåller två textrutor, en kryssruta, en knapp och en etikett (Klicka om du vill visa en bild i full storlek)

Skapa slutligen en händelsehanterare för händelsen LoginButton's Click. Från designern dubbelklickar du bara på knappkontrollen för att skapa den här händelsehanteraren.

Avgöra om de angivna autentiseringsuppgifterna är giltiga

Nu måste vi implementera uppgift 2 i händelsehanteraren Klicka på knappen – och avgöra om de angivna autentiseringsuppgifterna är giltiga. För att göra detta måste det finnas ett användararkiv som innehåller alla användares autentiseringsuppgifter så att vi kan avgöra om de angivna autentiseringsuppgifterna matchar med några kända autentiseringsuppgifter.

Före ASP.NET 2.0 var utvecklarna ansvariga för att implementera både sina egna användardata-lager och skriva koden för att verifiera de angivna autentiseringsuppgifterna mot lagret. De flesta utvecklare implementerar användararkivet i en databas och skapar en tabell med namnet Användare med kolumner som Användarnamn, Lösenord, E-post, LastLoginDate och så vidare. Den här tabellen skulle då ha en post per användarkonto. Att verifiera en användares angivna autentiseringsuppgifter skulle innebära att du frågar databasen efter ett matchande användarnamn och sedan ser till att lösenordet i databasen motsvarar det angivna lösenordet.

Med ASP.NET 2.0 bör utvecklare använda en av medlemskapsleverantörerna för att hantera användarlagringen. I den här självstudieserien använder vi SqlMembershipProvider, som använder en SQL Server-databas för användararkivet. När vi använder SqlMembershipProvider måste vi implementera ett specifikt databasschema som innehåller tabeller, vyer och lagrade procedurer som förväntas av providern. Vi kommer att undersöka hur du implementerar det här schemat i självstudien Skapa medlemskapsschemat i SQL Server . När medlemskapsprovidern är på plats är valideringen av användarens autentiseringsuppgifter lika enkel som att anropa medlemskapsklassensvalidateuser-metod (användarnamn, lösenord), som returnerar ett booleskt värde som anger om giltigheten för kombinationen av användarnamn och lösenord . Eftersom vi ännu inte har implementerat SqlMembershipProviders användararkiv kan vi inte använda medlemskapsklassens ValidateUser-metod just nu.

I stället för att ta dig tid att skapa en egen databastabell för anpassade användare (som skulle vara föråldrad när vi implementerade SqlMembershipProvider) hårdkodar vi i stället de giltiga autentiseringsuppgifterna på själva inloggningssidan. Lägg till följande kod i händelsehanteraren för Inloggningsknappens Klick-händelse:

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;
}

Som du ser finns det tre giltiga användarkonton – Scott, Jisun och Sam – och alla tre har samma lösenord ("lösenord"). Koden loopar genom matriserna för användare och lösenord som letar efter ett giltigt användarnamn och lösenordsmatchning. Om både användarnamnet och lösenordet är giltiga måste vi logga in på användaren och sedan omdirigera dem till rätt sida. Om autentiseringsuppgifterna är ogiltiga visar vi etiketten InvalidCredentialsMessage.

När en användare anger giltiga autentiseringsuppgifter nämnde jag att de sedan omdirigeras till "lämplig sida". Men vilken är lämplig sida? Kom ihåg att när en användare besöker en sida som de inte har behörighet att visa omdirigerar FormsAuthenticationModule dem automatiskt till inloggningssidan. På så sätt innehåller den den begärda URL:en i frågesträngen via parametern ReturnUrl. Om en användare försöker besöka ProtectedPage.aspx och inte har behörighet att göra det omdirigerar FormsAuthenticationModule dem till:

Login.aspx? ReturnUrl=ProtectedPage.aspx

När du har loggat in bör användaren omdirigeras tillbaka till ProtectedPage.aspx. Alternativt kan användare besöka inloggningssidan på egen hand. Efter att ha loggat in användaren ska de skickas till Default.aspx-sidan i rotmappen.

Logga in användaren

Förutsatt att de angivna autentiseringsuppgifterna är giltiga måste vi skapa ett formulärautentiseringsärende och därmed logga in användaren på webbplatsen. Klassen FormsAuthentication i namnområdet System.Web.Security innehåller olika metoder för att logga in och logga ut användare via formulärautentiseringssystemet. Det finns flera metoder i klassen FormsAuthentication, men de tre vi är intresserade av i det här läget är:

• GetAuthCookie (användarnamn, persistCookie) – skapar en formulärautentiseringsbiljett för det angivna namnanvändarnamnet. Sedan skapar och returnerar den här metoden ett HttpCookie-objekt som innehåller innehållet i autentiseringsbiljetten. Om persistCookie är sant skapas en beständig cookie.
• SetAuthCookie(username, persistCookie) – anropar metoden GetAuthCookie(username, persistCookie) för att generera formulärautentiseringscookie. Den här metoden lägger sedan till cookien som returneras av GetAuthCookie till cookies-samlingen (förutsatt att cookiesbaserad formulärautentisering används. Annars anropar den här metoden en intern klass som hanterar logiken för cookielösa biljetter).
• RedirectFromLoginPage(username, persistCookie) – den här metoden anropar SetAuthCookie(username, persistCookie) och omdirigerar sedan användaren till rätt sida.

GetAuthCookie är praktiskt när du behöver ändra autentiseringsbiljetten innan du skriver ut cookien till cookies-samlingen. SetAuthCookie är användbart om du vill skapa formulärautentiseringsbiljetten och lägga till den i samlingen Cookies, men inte vill omdirigera användaren till rätt sida. Du kanske vill behålla dem på inloggningssidan eller skicka dem till en alternativ sida.

Eftersom vi vill logga in på användaren och omdirigera dem till rätt sida ska vi använda RedirectFromLoginPage. Uppdatera LoginButtons Click-händelsehanterare och ersätt de två kommenterade TODO-raderna med följande kodrad:

FormsAuthentication.RedirectFromLoginPage (Användarnamn.Text, RememberMe.Checked);

När vi skapar formulärautentiseringsbiljetten använder vi egenskapen UserName TextBox Text för användarnamnsparametern för formulärautentiseringsbiljetten och det kontrollerade tillståndet för kryssrutan RememberMe för parametern persistCookie.

Om du vill testa inloggningssidan går du till den i en webbläsare. Börja med att ange ogiltiga autentiseringsuppgifter, till exempel ett användarnamn för "Nope" och ett lösenord för "fel". När du klickar på inloggningsknappen sker en återkoppling och etiketten InvalidCredentialsMessage visas.

Bild 10: Etiketten InvalidCredentialsMessage visas när ogiltiga autentiseringsuppgifter anges (klicka om du vill visa en bild i full storlek)

Ange sedan giltiga autentiseringsuppgifter och klicka på knappen Logga in. När postbacken sker denna gång skapas en formulärautentiseringsbiljett och du omdirigeras automatiskt tillbaka till Default.aspx. Nu har du loggat in på webbplatsen, även om det inte finns några visuella tips som anger att du är inloggad just nu. I steg 4 ser vi hur du programmatiskt avgör om en användare är inloggad eller inte samt hur du identifierar användaren som besöker sidan.

Steg 5 undersöker tekniker för att logga ut en användare från webbplatsen.

Skydda inloggningssidan

När användaren anger sina autentiseringsuppgifter och skickar formuläret för inloggningssidan överförs autentiseringsuppgifterna – inklusive lösenordet – via Internet till webbservern i klartext. Det innebär att alla hackare som sniffar nätverkstrafiken kan se användarnamnet och lösenordet. För att förhindra detta är det viktigt att kryptera nätverkstrafiken med hjälp av SSL (Secure Socket Layer). Detta säkerställer att autentiseringsuppgifterna (samt hela sidans HTML-kod) krypteras från det ögonblick de lämnar webbläsaren tills de tas emot av webbservern.

Om inte din webbplats innehåller känslig information behöver du bara använda SSL på inloggningssidan och på andra sidor där användarens lösenord annars skulle skickas via tråden i oformaterad text. Du behöver inte bekymra dig om att skydda formulärautentiseringsbiljetten eftersom den som standard är både krypterad och digitalt signerad (för att förhindra manipulering). En mer ingående diskussion om säkerheten för biljetter vid formulärautentisering presenteras i följande handledning.

Anmärkning

Många finansiella och medicinska webbplatser är konfigurerade för att använda SSL på alla sidor som är tillgängliga för autentiserade användare. Om du skapar en sådan webbplats kan du konfigurera formulärautentiseringssystemet så att formulärautentiseringsbiljetten endast överförs via en säker anslutning.

Steg 4: Identifiera autentiserade besökare och fastställa deras identitet

Nu har vi aktiverat formulärautentisering och skapat en rudimentär inloggningssida, men vi har ännu inte undersökt hur vi kan avgöra om en användare är autentiserad eller anonym. I vissa scenarier kanske vi vill visa olika data eller information beroende på om en autentiserad eller anonym användare besöker sidan. Dessutom behöver vi ofta känna till identiteten för den autentiserade användaren.

Nu ska vi utöka den befintliga Default.aspx sidan för att illustrera dessa tekniker. I Default.aspx lägger du till två panelkontroller, en med namnet AuthenticatedMessagePanel och en annan med namnet AnonymousMessagePanel. Lägg till en etikettkontroll med namnet WelcomeBackMessage i den första panelen. I den andra panelen lägger du till en HyperLink-kontroll och anger egenskapen Text till "Logga in" och egenskapen NavigateUrl till "~/Login.aspx". I det här läget bör deklarativ kod för Default.aspx se ut ungefär så här:

<%@ 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>

Som du förmodligen har gissat nu är tanken här att visa bara AuthenticatedMessagePanel för autentiserade besökare och bara AnonymousMessagePanel för anonyma besökare. För att göra detta måste vi ange de här panelernas synliga egenskaper beroende på om användaren är inloggad eller inte.

Egenskapen Request.IsAuthenticated returnerar ett booleskt värde som anger om begäran har autentiserats. Ange följande kod i Page_Load händelsehanterarkod:

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;
    }
}

Med den här koden på plats går du till Default.aspx via en webbläsare. Förutsatt att du ännu inte har loggat in visas en länk till inloggningssidan (se bild 11). Klicka på den här länken och logga in på webbplatsen. Som vi såg i steg 3, när du har angett dina autentiseringsuppgifter kommer du att återgå till Default.aspx, men den här gången visar sidan meddelandet "Välkommen tillbaka!" (se bild 12).

Bild 11: När du besöker anonymt visas en inloggningslänk

Bild 12: Autentiserade användare visas "Välkommen tillbaka!" Meddelande

Vi kan fastställa den för närvarande inloggade användarens identitet via HttpContext-objektetsanvändaregenskap. HttpContext-objektet representerar information om den aktuella begäran och är startsidan för sådana vanliga ASP.NET objekt som bland annat Svar, Begäran och Session. Egenskapen Användare representerar säkerhetskontexten för den aktuella HTTP-begäran och implementerar IPrincipal-gränssnittet.

Egenskapen Användare anges av FormsAuthenticationModule. När FormsAuthenticationModule hittar ett formulärautentiseringsärende i den inkommande begäran skapar det ett nytt GenericPrincipal-objekt och tilldelar det till egenskapen Användare.

Huvudobjekt (till exempel GenericPrincipal) ger information om användarens identitet och de roller som de tillhör. IPrincipal-gränssnittet definierar två medlemmar:

• IsInRole(roleName) – en metod som returnerar ett booleskt värde som anger om huvudnamnet tillhör den angivna rollen.
• Identitet – en egenskap som returnerar ett objekt som implementerar IIdentity-gränssnittet. IIdentity-gränssnittet definierar tre egenskaper: AuthenticationType, IsAuthenticated och Name.

Vi kan fastställa namnet på den aktuella besökaren med hjälp av följande kod:

string currentUsersName = User.Identity.Name; // Användarens nuvarande namn

När du använder formulärautentisering skapas ett FormsIdentity-objekt för egenskapen GenericPrincipals identitet. FormsIdentity-klassen returnerar alltid strängen "Forms" för egenskapen AuthenticationType och true för dess IsAuthenticated-egenskap. Egenskapen Namn returnerar det användarnamn som angavs när formulärautentiseringsbiljetten skapades. Förutom dessa tre egenskaper, ger FormsIdentity åtkomst till den underliggande autentiseringsbiljetten via Ticket-egenskapen. Egenskapen Ticket returnerar ett objekt av typen FormsAuthenticationTicket, som har egenskaper som Expiration, IsPersistent, IssueDate, Name och så vidare.

Det viktiga att ta bort här är att användarnamnsparametern som anges i FormsAuthentication.GetAuthCookie(username, persistCookie), FormsAuthentication.SetAuthCookie(username, persistCookie) och FormsAuthentication.RedirectFromLoginPage(username, persistCookie) är samma värde som returneras av User.Identity.Name. Dessutom är autentiseringsbiljetten som skapats med dessa metoder tillgänglig genom att använda User.Identity till ett FormsIdentity-objekt och sedan komma åt egenskapen Ticket:

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

Nu ska vi ange ett mer personligt meddelande i Default.aspx. Uppdatera Page_Load händelsehanteraren så att egenskapen WelcomeBackMessage Label's Text tilldelas strängen "Välkommen tillbaka, användarnamn!"

WelcomeBackMessage.Text = "Välkommen tillbaka, " + User.Identity.Name + "!";

Bild 13 visar effekten av den här ändringen (när du loggar in som användare Scott).

Bild 13: Välkomstmeddelandet innehåller den inloggade användarens namn

Använda kontrollerna LoginView och LoginName

Att visa olika innehåll för autentiserade och anonyma användare är ett vanligt krav; det är också att visa namnet på den användare som är inloggad. Därför innehåller ASP.NET två webbkontroller som tillhandahåller samma funktioner som visas i bild 13, men utan att behöva skriva en enda kodrad.

LoginView-kontrollen är en mallbaserad webbkontroll som gör det enkelt att visa olika data för autentiserade och anonyma användare. LoginView innehåller två fördefinierade mallar:

• AnonymousTemplate – alla markeringar som läggs till i den här mallen visas endast för anonyma besökare.
• LoggedInTemplate – mallens markering visas endast för autentiserade användare.

Nu ska vi lägga till LoginView-kontrollen på webbplatsens huvudsida, Site.master. Men i stället för att bara lägga till LoginView-kontrollen ska vi lägga till både en ny ContentPlaceHolder-kontroll och sedan placera LoginView-kontrollen i den nya ContentPlaceHolder. Grunden för detta beslut kommer att bli uppenbar inom kort.

Anmärkning

Förutom AnonymousTemplate och LoggedInTemplate kan LoginView-kontrollen innehålla rollspecifika mallar. Rollspecifika mallar visar endast markering för de användare som tillhör en angiven roll. Vi kommer att undersöka rollbaserade funktioner i LoginView-kontrollen i en framtida handledning.

Börja med att lägga till en ContentPlaceHolder med namnet LoginContent på huvudsidan i navigerings-div-elementet<>. Du kan helt enkelt dra en ContentPlaceHolder-kontroll från verktygslådan till källvyen och placera den resulterande markeringen precis ovanför "TODO: Menyn kommer att gå hit...".

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

Lägg sedan till en LoginView-kontroll i LoginContent ContentPlaceHolder. Innehåll som placeras i huvudsidans ContentPlaceHolder-kontroller betraktas som standardinnehåll för ContentPlaceHolder. Det innebär att ASP.NET-sidor som använder den här huvudsidan kan ange sitt eget innehåll för varje ContentPlaceHolder eller använda huvudsidans standardinnehåll.

Inloggningsvyn och andra inloggningsrelaterade kontroller finns på fliken Inloggning i verktygslådan.

Bild 14: LoginView-kontrollen i verktygslådan

Lägg sedan till två <br/> element direkt efter LoginView-kontrollen, men fortfarande i ContentPlaceHolder. Nu bör navigerings-div-elementets <> markering se ut så här:

<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>

LoginView-mallarna kan definieras från designern eller deklarativ kod. Från Visual Studio Designer expanderar du Den smarta taggen för LoginView, som visar de konfigurerade mallarna i en listruta. Skriv in texten "Hello, stranger" i AnonymousTemplate; Lägg sedan till en HyperLink-kontroll och ange egenskaperna Text och NavigateUrl till "Log In" respektive "~/Login.aspx".

När du har konfigurerat AnonymousTemplate växlar du till LoggedInTemplate och anger texten "Välkommen tillbaka". Dra sedan en LoginName-kontroll från verktygslådan till LoggedInTemplate och placera den direkt efter texten Välkommen tillbaka. LoginName-kontrollen, som namnet antyder, visar namnet på den inloggade användaren. Internt matar LoginName-kontrollen helt enkelt ut egenskapen User.Identity.Name

När du har gjort dessa tillägg till LoginView-mallarna bör markeringarna se ut ungefär så här:

<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>

Med detta tillägg till site.master-huvudsidan visar varje sida på vår webbplats ett annat meddelande beroende på om användaren är autentiserad. Bild 15 visar sidan Default.aspx när användaren Jisun besöker den via en webbläsare. Meddelandet "Välkommen tillbaka, Jisun" upprepas två gånger: en gång i huvudsidans navigeringsavsnitt till vänster (via loginview-kontrollen som vi just lade till) och en gång i Default.aspx innehållsområde (via panelkontroller och programmeringslogik).

Bild 15: LoginView-kontrollen visar "Välkommen tillbaka, Jisun".

Eftersom vi har lagt till LoginView på huvudsidan kan den visas på varje sida på vår webbplats. Det kan dock finnas webbsidor där vi inte vill visa det här meddelandet. En sådan sida är inloggningssidan, eftersom en länk till inloggningssidan verkar vara felplacerad där. Eftersom vi har placerat LoginView-kontrollen i en ContentPlaceHolder på huvudsidan kan vi åsidosätta den här standardmarkeringen på vår innehållssida. Öppna Login.aspx och gå till Designer. Eftersom vi inte uttryckligen har definierat en innehållskontroll i Login.aspx för LoginContent ContentPlaceHolder på huvudsidan, visar inloggningssidan huvudsidans standardmarkering för den här ContentPlaceHolder. Du kan se detta via Designer – LoginContent ContentPlaceHolder visar standardmarkeringen (LoginView-kontrollen).

Bild 16: Inloggningssidan visar standardinnehållet för huvudsidans LoginContent ContentPlaceHolder (Klicka om du vill visa en bild i full storlek)

Om du vill åsidosätta standardmarkeringen för LoginContent ContentPlaceHolder högerklickar du bara på regionen i Designer och väljer alternativet Skapa anpassat innehåll på snabbmenyn. (När du använder Visual Studio 2008 innehåller ContentPlaceHolder en smart tagg som, när den väljs, erbjuder samma alternativ.) Detta lägger till en ny innehållskontroll i sidans markering och gör att vi kan definiera anpassat innehåll för den här sidan. Du kan lägga till ett anpassat meddelande här, till exempel "Logga in...", men låt oss lämna det tomt.

Anmärkning

När du skapar anpassat innehåll i Visual Studio 2005 skapas en tom innehållskontroll på sidan ASP.NET. I Visual Studio 2008 kopierar dock skapandet av anpassat innehåll huvudsidans standardinnehåll till den nyligen skapade innehållskontrollen. Om du använder Visual Studio 2008 måste du rensa innehållet som kopierats från huvudsidan när du har skapat den nya innehållskontrollen.

Bild 17 visar sidan Login.aspx när den besöks från en webbläsare när ändringen har slutförts. Observera att det inte finns något meddelande om "Hej, främling" eller "Välkommen tillbaka, användarnamn" i det vänstra navigerings-div <> som det finns när du besöker Default.aspx.

Bild 17: Inloggningssidan döljer markup för Default LoginContent ContentPlaceHolder (Klicka om du vill visa en bild i full storlek)

Steg 5: Logga ut

I steg 3 tittade vi på att skapa en inloggningssida för att logga in en användare på webbplatsen, men vi har ännu inte sett hur du loggar ut en användare. Förutom metoder för att logga in en användare i tillhandahåller klassen FormsAuthentication även en SignOut-metod. SignOut-metoden förstör helt enkelt formulärautentiseringsbiljetten och loggar därmed ut användaren från webbplatsen.

Att erbjuda en utloggningslänk är en sådan vanlig funktion att ASP.NET innehåller en kontroll som är särskilt utformad för att logga ut en användare. Kontrollen LoginStatus visar antingen en "Login" LinkButton eller en "Logout" LinkButton, beroende på användarens autentiseringsstatus. En "Login" LinkButton återges för anonyma användare, medan en "Logout" LinkButton visas för autentiserade användare. Texten för linkbuttonerna "Login" och "Logout" kan konfigureras via egenskaperna LoginStatus LoginText och LogoutText.

När du klickar på "Logga in"-knappen skapas ett återanrop, från vilket en omdirigering sker till inloggningssidan. Om du klickar på LinkButton för utloggning anropar du metoden FormsAuthentication.SignOff och omdirigerar sedan användaren till en sida. Sidan som den inloggade användaren omdirigeras till beror på egenskapen LogoutAction, som kan tilldelas något av följande tre värden:

• Uppdatera – standardvärdet; omdirigerar användaren till den sida som de just besökte. Om sidan de just besökte inte tillåter anonyma användare omdirigerar FormsAuthenticationModule automatiskt användaren till inloggningssidan.

Du kanske är nyfiken på varför en omdirigering utförs här. Varför behövs den explicita omdirigeringen om användaren vill vara kvar på samma sida? Anledningen är att när "Logoff" LinkButton klickas har användaren fortfarande formulärautentiseringsbiljetten i sin cookies-samling. Därför är postback-begäran en autentiserad begäran. LoginStatus-kontrollen anropar SignOut-metoden, men det händer när FormsAuthenticationModule har autentiserat användaren. Därför gör en explicit omdirigering att webbläsaren begär sidan igen. När webbläsaren begär sidan på nytt har formulärautentiseringsbiljetten tagits bort och därför är den inkommande begäran anonym.

• Omdirigering – användaren omdirigeras till den URL som anges av egenskapen LoginStatus LogoutPageUrl.
• RedirectToLoginPage – användaren omdirigeras till inloggningssidan.

Nu ska vi lägga till en LoginStatus-kontroll på huvudsidan och konfigurera den så att den använder omdirigeringsalternativet för att skicka användaren till en sida som visar ett meddelande som bekräftar att de har loggats ut. Börja med att skapa en sida i rotkatalogen med namnet Logout.aspx. Glöm inte att associera den här sidan med huvudsidan site.master. Ange sedan ett meddelande i sidans markering som förklarar för användaren att de har loggats ut.

Gå sedan tillbaka till huvudsidan site.master och lägg till en LoginStatus-kontroll under LoginView på LoginContent ContentPlaceHolder. Ange LoginStatus-kontrollens LogoutAction-egenskap till Omdirigering och LogoutPageUrl-egenskapen till "~/Logout.aspx".

<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>

Eftersom LoginStatus ligger utanför LoginView-kontrollen visas den för både anonyma och autentiserade användare, men det är OK eftersom LoginStatus visar en "Login" eller "Logout" LinkButton korrekt. Med tillägget av LoginStatus-kontrollen är hyperlänken "Logga in" i AnonymousTemplate överflödig, så ta bort den.

Bild 18 visar Default.aspx när Jisun besöker. Observera att den vänstra kolumnen visar meddelandet "Välkommen tillbaka, Jisun" tillsammans med en länk för att logga ut. När du klickar på utloggningen orsakar LinkButton ett återanrop, loggar ut Jisun från systemet och omdirigerar henne sedan till Logout.aspx. Som bild 19 visar, när Jisun når Logout.aspx har hon redan loggats ut och är därför anonym. Den vänstra kolumnen visar därför texten "Välkommen, främling" och en länk till inloggningssidan.

Bild 18: Default.aspx Visar "Välkommen tillbaka, Jisun" tillsammans med en "Utloggning" LinkButton (Klicka om du vill visa en bild i full storlek)

Bild 19: Logout.aspx Visar "Välkommen, främling" Tillsammans med en "Inloggning" LinkButton (Klicka för att visa full storlek bild)

Anmärkning

Jag rekommenderar att du anpassar Logout.aspx sidan för att dölja huvudsidans LoginContent ContentPlaceHolder (som vi gjorde för Login.aspx i steg 4). Orsaken är att linkbuttonen "Login" som återges av LoginStatus-kontrollen (den under "Hello, stranger") skickar användaren till inloggningssidan och skickar den aktuella URL:en i parametern ReturnUrl querystring. Kort och kort, om en användare som har loggat ut klickar på inloggningsstatusens "Inloggning" LinkButton, och sedan loggar in, omdirigeras de tillbaka till Logout.aspx, vilket enkelt kan förvirra användaren.

Sammanfattning

I den här självstudien började vi med en undersökning av arbetsflödet för formulärautentisering och vände oss sedan till att implementera formulärautentisering i ett ASP.NET program. Formulärautentisering drivs av FormsAuthenticationModule, som har två ansvarsområden: att identifiera användare baserat på deras formulärautentiseringsbiljett och omdirigera obehöriga användare till inloggningssidan.

.NET Frameworks FormsAuthentication-klass innehåller metoder för att skapa, inspektera och ta bort formulärautentiseringsbiljetter. Egenskapen Request.IsAuthenticated och användarobjektet ger ytterligare programmatiskt stöd för att avgöra om en begäran autentiseras och information om användarens identitet. Det finns även webkontrollerna LoginView, LoginStatus och LoginName, som ger utvecklare ett snabbt och kodfritt sätt att utföra många vanliga inloggningsrelaterade uppgifter. Vi kommer att undersöka dessa och andra inloggningsrelaterade webbkontroller i större detalj i framtida självstudier.

Den här handledningen gav en snabb översikt över autentisering med formulär. Vi undersökte inte de olika konfigurationsalternativen, tittade på hur cookielösa formulärautentiseringsbiljetter fungerar eller hur ASP.NET skyddar innehållet i formulärautentiseringsbiljetten.

Lycka till med programmerandet!

Ytterligare läsning

Mer information om de ämnen som beskrivs i den här självstudien finns i följande resurser:

• Ändringar mellan IIS6 och IIS7 Security
• Inloggningskontroller för ASP.NET
• Professionell ASP.NET 2.0 Säkerhet, Användarhantering och Rollhantering (ISBN: 978-0-7645-9698-8)
• Elementet <authentication>
• Elementet <forms> för <authentication>

Videoutbildning om ämnen som finns i den här handledningen

• Använda grundläggande formulärautentisering i ASP.NET

Om författaren

Scott Mitchell, författare till sju ASP/ASP.NET-böcker och grundare av 4GuysFromRolla.com, har arbetat med Microsofts webbtekniker sedan 1998. Scott arbetar som oberoende konsult, tränare och författare. Hans senaste bok är Sams Teach Yourself ASP.NET 2.0 på 24 timmar. Han kan nås på mitchell@4GuysFromRolla.com.

Speciellt tack till ...

Den här självstudieserien granskades av många användbara granskare. Leadgranskare för den här självstudien var [namnet]. Den här självstudieserien granskades av många hjälpsamma granskare. Huvudgranskare för den här självstudien är Alicja Maziarz, John Suru och Teresa Murphy. Vill du granska mina kommande MSDN-artiklar? Om så är fallet, hör av dig på mitchell@4GuysFromRolla.com.

Föregåendenästa