Een overzicht van formulierverificatie (C#)

door Scott Mitchell

Opmerking

Sinds dit artikel is geschreven, zijn de ASP.NET Lidmaatschapsproviders vervangen door ASP.NET Identity. We raden u ten zeerste aan om apps bij te werken om gebruik te maken van het ASP.NET Identity-platform in plaats van de Membership-providers die op het moment van schrijven in dit artikel werden aanbevolen. ASP.NET Identity heeft een aantal voordelen ten opzichte van het ASP.NET Lidmaatschapssysteem, waaronder:

• Betere prestaties
• Verbeterde uitbreidbaarheid en testbaarheid
• Ondersteuning voor OAuth, OpenID Connect en tweeledige verificatie
• Ondersteuning voor claim-gebaseerde identiteit
• Betere interoperabiliteit met ASP.Net Core

Code downloaden of PDF- downloaden

In deze zelfstudie gaan we van alleen discussie tot implementatie; in het bijzonder gaan we kijken naar het implementeren van formulierverificatie. De webtoepassing die we in deze zelfstudie gaan maken, wordt verder gebouwd in de volgende zelfstudies, omdat we overstappen van eenvoudige formulierverificatie naar lidmaatschap en rollen.

Zie deze video voor meer informatie over dit onderwerp: Basisformulierverificatie gebruiken in ASP.NET.

Introductie

In de voorgaande zelfstudie hebben we de verschillende verificatie-, autorisatie- en gebruikersaccountopties besproken die worden geboden door ASP.NET. In deze zelfstudie gaan we van alleen discussie tot implementatie; in het bijzonder gaan we kijken naar het implementeren van formulierverificatie. De webtoepassing die we in deze zelfstudie gaan maken, wordt verder gebouwd in de volgende zelfstudies, omdat we overstappen van eenvoudige formulierverificatie naar lidmaatschap en rollen.

Deze zelfstudie begint met een uitgebreid overzicht van de werkstroom voor formulierverificatie, een onderwerp dat we in de vorige zelfstudie hebben besproken. Vervolgens maken we een ASP.NET-website om de concepten van formulierauthenticatie te demonstreren. Vervolgens configureren we de site voor het gebruik van formulierverificatie, maken we een eenvoudige aanmeldingspagina en zien we hoe u in code kunt bepalen of een gebruiker is geverifieerd en, als dat het zo is, de gebruikersnaam waarmee ze zijn aangemeld.

Informatie over de werkstroom voor formulierverificatie, het inschakelen ervan in een webtoepassing en het maken van de aanmeldings- en afmeldingspagina's zijn allemaal belangrijke stappen bij het bouwen van een ASP.NET-toepassing die gebruikersaccounts ondersteunt en gebruikers verifieert via een webpagina. Daarom – en omdat deze zelfstudies op elkaar voortbouwen - zou ik u aanmoedigen om deze zelfstudie volledig te doorlopen voordat u verdergaat met de volgende zelfstudie, zelfs als u al ervaring hebt met het configureren van formulierverificatie in eerdere projecten.

Informatie over de werkstroom voor formulierverificatie

Wanneer de ASP.NET runtime een aanvraag voor een ASP.NET-resource verwerkt, zoals een ASP.NET-pagina of ASP.NET-webservice, genereert de aanvraag een aantal gebeurtenissen tijdens de levenscyclus. Er zijn gebeurtenissen aan het begin en het einde van het verzoek, die worden gegenereerd wanneer de aanvraag wordt geverifieerd en geautoriseerd, een gebeurtenis die wordt gegenereerd in het geval van een niet-verwerkte uitzondering, enzovoort. Raadpleeg de gebeurtenissen van het HttpApplication-object om een volledige lijst van de gebeurtenissen te bekijken.

HTTP-modules zijn beheerde klassen waarvan de code wordt uitgevoerd als reactie op een bepaalde gebeurtenis in de levenscyclus van de aanvraag. ASP.NET wordt geleverd met een aantal HTTP-modules die achter de schermen essentiële taken uitvoeren. Twee ingebouwde HTTP-modules die met name relevant zijn voor onze discussie zijn:

• FormsAuthenticationModule – verifieert de gebruiker door het formulierverificatieticket te inspecteren, dat meestal is opgenomen in de cookiesverzameling van de gebruiker. Als er geen formulierverificatieticket aanwezig is, is de gebruiker anoniem.
• UrlAuthorizationModule – bepaalt of de huidige gebruiker gemachtigd is om toegang te krijgen tot de aangevraagde URL. Deze module bepaalt de instantie door de autorisatieregels te raadplegen die zijn opgegeven in de configuratiebestanden van de toepassing. ASP.NET bevat ook de FileAuthorizationModule instantie die de autoriteit bepaalt door de ACL's van de aangevraagde bestanden te raadplegen.

De FormsAuthenticationModule probeert de gebruiker te authenticeren voordat UrlAuthorizationModule (en FileAuthorizationModule) worden uitgevoerd. Als de gebruiker die de aanvraag indient, niet gemachtigd is voor toegang tot de aangevraagde resource, beëindigt de autorisatiemodule de aanvraag en retourneert de HTTP 401 Niet-geautoriseerde status. In Windows-verificatiescenario's wordt de HTTP 401-status geretourneerd naar de browser. Deze statuscode zorgt ervoor dat de browser de gebruiker om hun referenties vraagt via een modaal dialoogvenster. Met formulierverificatie wordt de HTTP 401 Niet-geautoriseerde status echter nooit naar de browser verzonden omdat de FormsAuthenticationModule deze status detecteert en deze wijzigt om de gebruiker om te leiden naar de aanmeldingspagina (via een HTTP 302-omleidingsstatus ).

De verantwoordelijkheid van de aanmeldingspagina is om te bepalen of de gebruikersgegevens geldig zijn, en, zo ja, een authenticatieticket voor formulieren te maken en de gebruiker te verwijzen naar de pagina die zij probeerden te bezoeken. Het authenticatieticket wordt opgenomen in alle daaropvolgende aanvragen voor de pagina's op de website, die door de FormsAuthenticationModule wordt gebruikt om de gebruiker te identificeren.

Afbeelding 1: De werkstroom voor formulierverificatie

Het verificatieticket onthouden tijdens paginabezoeken

Nadat u zich hebt aangemeld, moet het formulierverificatieticket worden teruggestuurd naar de webserver op elke aanvraag, zodat de gebruiker blijft aangemeld terwijl hij of zij door de site bladert. Dit wordt meestal bereikt door het verificatieticket in de cookiesverzameling van de gebruiker te plaatsen. Cookies zijn kleine tekstbestanden die zich op de computer van de gebruiker bevinden en worden verzonden in de HTTP-headers op elke aanvraag naar de website die de cookie heeft gemaakt. Zodra het formulierverificatieticket is gemaakt en opgeslagen in de cookies van de browser, verzendt elk volgend bezoek aan die site het verificatieticket samen met de aanvraag, waardoor de gebruiker wordt geïdentificeerd.

Een aspect van cookies is hun vervaltermijn, de datum en tijd waarop de browser de cookie verwijdert. Wanneer de cookie voor formulierverificatie verloopt, kan de gebruiker niet meer worden geverifieerd en dus anoniem worden. Wanneer een gebruiker vanuit een openbare terminal bezoekt, is de kans groot dat hun verificatieticket verloopt wanneer ze hun browser sluiten. Wanneer dezelfde gebruiker echter thuis bezoekt, kan het zijn dat het verificatieticket opnieuw moet worden onthouden tijdens het opnieuw opstarten van de browser, zodat ze zich niet telkens opnieuw hoeven aan te melden wanneer ze de site bezoeken. Deze beslissing wordt vaak genomen door de gebruiker in de vorm van een selectievakje 'Mij onthouden' op de aanmeldingspagina. In stap 3 bekijken we hoe we een selectievakje 'Mij onthouden' implementeren op de aanmeldingspagina. In de volgende handleiding worden de time-outinstellingen voor verificatietickets in detail besproken.

Opmerking

Het is mogelijk dat de gebruikersagent die wordt gebruikt om zich aan te melden bij de website mogelijk geen cookies ondersteunt. In dat geval kan ASP.NET verificatietickets zonder cookies gebruiken. In deze modus wordt het verificatieticket gecodeerd in de URL. In de volgende zelfstudie bekijken we wanneer cookieloze verificatietickets worden gebruikt en hoe ze worden gemaakt en beheerd.

Het bereik van formulierverificatie

De FormsAuthenticationModule beheerde code maakt deel uit van de ASP.NET runtime. Vóór versie 7 van de IIS-webserver (Internet Information Services) van Microsoft was er een duidelijke barrière tussen de HTTP-pijplijn van IIS en de pijplijn van de ASP.NET runtime. Kortom, in IIS 6 en eerder, wordt de FormsAuthenticationModule alleen uitgevoerd wanneer een verzoek wordt gedelegeerd van IIS naar de ASP.NET-runtime. IIS verwerkt standaard statische inhoud zelf, zoals HTML-pagina's en CSS- en afbeeldingsbestanden, en geeft alleen aanvragen af aan de ASP.NET runtime wanneer een pagina met een extensie van .aspx, .asmx of .ashx wordt aangevraagd.

IIS 7 maakt echter geïntegreerde IIS- en ASP.NET-pijplijnen mogelijk. Met enkele configuratie-instellingen kunt u IIS 7 instellen om de FormsAuthenticationModule voor alle aanvragen aan te roepen. Bovendien kunt u met IIS 7 URL-autorisatieregels definiëren voor bestanden van elk type. Zie Wijzigingen tussen IIS6 en IIS7 Security, Your Web Platform Security en Understanding IIS7 URL Authorization voor meer informatie.

Lang verhaal kort, in versies vóór IIS 7, kunt u alleen formulierverificatie gebruiken om resources te beveiligen die worden verwerkt door de ASP.NET runtime. Op dezelfde manier worden URL-autorisatieregels alleen toegepast op resources die worden verwerkt door de ASP.NET runtime. Maar met IIS 7 is het mogelijk om de FormsAuthenticationModule en UrlAuthorizationModule te integreren in de HTTP-pijplijn van IIS, waardoor deze functionaliteit wordt uitgebreid naar alle aanvragen.

Stap 1: een ASP.NET-website maken voor deze reeks zelfstudies

Om het breedst mogelijke publiek te bereiken, wordt de ASP.NET website die we in deze reeks gaan bouwen, gemaakt met de gratis versie van Microsoft van Visual Studio 2008, Visual Web Developer 2008. We implementeren het SqlMembershipProvider gebruikersarchief in een Microsoft SQL Server 2005 Express Edition-database . Als u Visual Studio 2005 of een andere versie van Visual Studio 2008 of SQL Server gebruikt, hoeft u zich geen zorgen te maken. De stappen zijn bijna identiek en eventuele niet-triviale verschillen worden opgemerkt.

Opmerking

De demowebtoepassing die in elke zelfstudie wordt gebruikt, is beschikbaar als download. Deze downloadbare toepassing is gemaakt met Visual Web Developer 2008 gericht op .NET Framework versie 3.5. Omdat de toepassing is gericht op .NET 3.5, bevat het bijbehorende Web.config bestand aanvullende, 3.5-specifieke configuratie-elementen. Lang verhaal kort, als u .NET 3.5 nog moet installeren op uw computer, werkt de downloadbare webtoepassing niet zonder eerst de 3.5-specifieke markering uit Web.configte verwijderen.

Voordat we formulierverificatie kunnen configureren, hebben we eerst een ASP.NET website nodig. Begin met het maken van een nieuwe ASP.NET website op basis van een bestandssysteem. Hiervoor start u Visual Web Developer en gaat u naar het menu Bestand en kiest u Nieuwe website, waarin het dialoogvenster Nieuwe website wordt weergegeven. Kies de ASP.NET websitesjabloon, stel de vervolgkeuzelijst Locatie in op Bestandssysteem, kies een map om de website te plaatsen en stel de taal in op C#. Hiermee maakt u een nieuwe website met een Default.aspx ASP.NET pagina, een App_Data map en een Web.config bestand.

Opmerking

Visual Studio ondersteunt twee modi van projectbeheer: websiteprojecten en webtoepassingsprojecten. Websiteprojecten hebben geen projectbestand, terwijl Web Application Projects de projectarchitectuur in Visual Studio .NET 2002/2003 nabootsen. Ze bevatten een projectbestand en compileren de broncode van het project in één assembly, die in de map /bin wordt geplaatst. Visual Studio 2005 ondersteunt aanvankelijk alleen websiteprojecten, hoewel het webtoepassingsprojectmodel opnieuw is geïntroduceerd met Service Pack 1; Visual Studio 2008 biedt beide projectmodellen. De edities Visual Web Developer 2005 en 2008 ondersteunen echter alleen websiteprojecten. Ik gebruik het websiteprojectmodel. Als u een niet-Express-editie gebruikt en in plaats daarvan het webtoepassingsprojectmodel wilt gebruiken, kunt u dit doen, maar houd er rekening mee dat er mogelijk verschillen zijn tussen wat u op het scherm ziet en de stappen die u moet uitvoeren ten opzichte van de schermafbeeldingen die in deze zelfstudies worden weergegeven en instructies.

Afbeelding 2: Een nieuw bestand System-Based website maken (klik hier om de volledige afbeelding weer te geven)

Een basispagina toevoegen

Voeg vervolgens een nieuwe basispagina toe aan de site in de hoofdmap met de naam Site.master. Met basispagina's kan een paginaontwikkelaar een sitebrede sjabloon definiëren die kan worden toegepast op ASP.NET pagina's. Het belangrijkste voordeel van basispagina's is dat de algehele weergave van de site op één locatie kan worden gedefinieerd, zodat u de indeling van de site eenvoudig kunt bijwerken of aanpassen.

Afbeelding 3: Een basispagina met de naam Site.master toevoegen aan de website (klik hier om de volledige afbeelding weer te geven)

Definieer hier de pagina-indeling voor de hele site op de basispagina. U kunt de ontwerpweergave gebruiken en de gewenste indelings- of webbesturingselementen toevoegen, of u kunt de opmaak handmatig toevoegen in de bronweergave. Ik heb de indeling van mijn basispagina gestructureerd om de indeling na te bootsen die wordt gebruikt in mijn werk met gegevens in ASP.NET 2.0-zelfstudiereeks (zie afbeelding 4). De masterpagina maakt gebruik van trapsgewijze opmaakmodellen voor het positioneren en de stijlen, met de CSS-instellingen die zijn gedefinieerd in het bestand Style.css (dat is bijgevoegd bij deze zelfstudie). Hoewel u niet kunt zien uit de onderstaande markeringen, worden de CSS-regels gedefinieerd, zodat de inhoud van het navigatie-div-element <>absoluut is ingesteld, zodat deze aan de linkerkant wordt weergegeven en een vaste breedte van 200 pixels heeft.

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

Een basispagina definieert zowel de statische pagina-indeling als de regio's die kunnen worden bewerkt door de ASP.NET pagina's die gebruikmaken van de basispagina. Deze bewerkbare inhoudsregio's worden aangegeven door de ContentPlaceHolder controle, die zichtbaar kan zijn binnen de inhoud <div>. Onze basispagina heeft één ContentPlaceHolder (MainContent), maar de basispagina's hebben mogelijk meerdere ContentPlaceHolders.

Wanneer de bovenstaande opmaak is ingevoerd, wordt de indeling van de hoofdpagina weergegeven in de ontwerpweergave. Alle ASP.NET pagina's die gebruikmaken van deze basispagina hebben deze uniforme indeling, met de mogelijkheid om de markeringen voor de MainContent regio op te geven.

Afbeelding 4: De basispagina, wanneer deze wordt bekeken in de ontwerpweergave (klik hier om de afbeelding op volledige grootte weer te geven)

Inhoudspagina's maken

Op dit moment hebben we een Default.aspx pagina op onze website, maar het maakt niet gebruik van de basispagina die we zojuist hebben gemaakt. Hoewel het mogelijk is om de declaratieve markeringen van een webpagina te bewerken om een basispagina te gebruiken, is het eenvoudiger om de pagina te verwijderen en opnieuw toe te voegen aan het project, waarbij u de basispagina opgeeft die u wilt gebruiken. Verwijder daarom eerst Default.aspx uit het project.

Klik vervolgens met de rechtermuisknop op de projectnaam in Solution Explorer en kies ervoor om een nieuw webformulier met de naam Default.aspx toe te voegen. Schakel deze keer het selectievakje Basispagina selecteren in en kies de basispagina Site.master in de lijst.

Afbeelding 5: Een nieuwe Default.aspx pagina toevoegen om een basispagina te selecteren (klik hier om een volledige afbeelding weer te geven)

Afbeelding 6: De basispagina Site.master gebruiken

Opmerking

Als u het webtoepassingsprojectmodel gebruikt, bevat het dialoogvenster Nieuw item toevoegen geen selectievakje Basispagina selecteren. In plaats daarvan moet u een item van het type "Web Content Form" toevoegen. Nadat u "Web Content Form" hebt gekozen en op Toevoegen hebt geklikt, zal Visual Studio hetzelfde dialoogvenster "Hoofdformulier selecteren" weergeven als in figuur 6.

De declaratieve opmaak van de nieuwe Default.aspx pagina bevat alleen een @Page instructie die het pad naar het basispaginabestand en een inhoudsbeheer voor de MainContent ContentPlaceHolder van de basispagina aangeeft.

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

Laat voorlopig Default.aspx leeg. We zullen er later in deze handleiding op terugkomen om inhoud toe te voegen.

Opmerking

Onze basispagina bevat een sectie voor een menu of een andere navigatie-interface. We zullen in een toekomstige zelfstudie een dergelijke interface maken.

Stap 2: Formulierverificatie inschakelen

Nu de ASP.NET website is gemaakt, is de volgende taak het inschakelen van formulierverificatie. De verificatieconfiguratie van de toepassing wordt opgegeven via het <authentication> element in Web.config. Het <authentication> element bevat één kenmerk benoemde modus waarmee het verificatiemodel wordt opgegeven dat door de toepassing wordt gebruikt. Dit kenmerk kan een van de volgende vier waarden hebben:

• Windows , zoals besproken in de vorige zelfstudie, wanneer een toepassing gebruikmaakt van Windows-verificatie, is het de verantwoordelijkheid van de webserver om de bezoeker te verifiëren. Dit gebeurt meestal via Basic-, Digest- of Geïntegreerde Windows-verificatie.
• Formulieren: gebruikers worden geverifieerd via een formulier op een webpagina.
• Passport: gebruikers worden geverifieerd met behulp van het Passport Network van Microsoft.
• Geen: er wordt geen verificatiemodel gebruikt; alle bezoekers zijn anoniem.

Standaard gebruiken ASP.NET toepassingen Windows-verificatie. Als u het verificatietype wilt wijzigen in formulierverificatie, moeten we het moduskenmerk van het <authentication> element wijzigen in Formulieren.

Als uw project nog geen Web.config bestand bevat, voegt u er nu een toe door er met de rechtermuisknop op de projectnaam in Solution Explorer te klikken, nieuw item toevoegen te kiezen en vervolgens een webconfiguratiebestand toe te voegen.

Afbeelding 7: Als uw project nog geen Web.configbevat, voegt u het nu toe (klik hier om de volledige afbeelding weer te geven)

Zoek vervolgens het <authentication> element en werk het bij om formulierverificatie te gebruiken. Na deze wijziging moet de opmaak van het Web.config-bestand er ongeveer als volgt uitzien:

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

Opmerking

Omdat Web.config een XML-bestand is, is casing belangrijk. Zorg ervoor dat u het moduskenmerk instelt op Formulieren, met een hoofdletter 'F'. Als u een andere behuizing gebruikt, zoals 'formulieren', ontvangt u een configuratiefout bij het bezoeken van de site via een browser.

Het <authentication> element kan eventueel een <forms> onderliggend element bevatten dat verificatiespecifieke instellingen voor formulieren bevat. Voorlopig gebruiken we alleen de standaardinstellingen voor formulierverificatie. In de volgende handleiding gaan we het <forms> kindelement nader bekijken.

Stap 3: de aanmeldingspagina bouwen

Om formulierverificatie te ondersteunen heeft onze website een aanmeldingspagina nodig. Zoals wordt beschreven in de sectie 'Understanding the Forms Authentication Workflow', wordt de FormsAuthenticationModule gebruiker automatisch omgeleid naar de aanmeldingspagina als ze proberen toegang te krijgen tot een pagina die ze niet mogen bekijken. Er zijn ook ASP.NET webbesturingselementen waarmee een koppeling naar de aanmeldingspagina voor anonieme gebruikers wordt weergegeven. Dit roept de vraag op: "Wat is de URL van de aanmeldingspagina?"

Standaard verwacht het formulierverificatiesysteem dat de aanmeldingspagina Login.aspx wordt genoemd en in de hoofdmap van de webtoepassing wordt geplaatst. Als u een andere aanmeldingspagina-URL wilt gebruiken, kunt u dit doen door deze op te geven in Web.config. In de volgende zelfstudie ziet u hoe u dit doet.

De aanmeldingspagina heeft drie verantwoordelijkheden:

1. Geef een interface op waarmee de bezoeker zijn referenties kan invoeren.
2. Bepaal of de ingediende referenties geldig zijn.
3. Log de gebruiker in door het authenticatieticket voor formulieren te maken.

De gebruikersinterface van de aanmeldingspagina maken

Laten we beginnen met de eerste taak. Voeg een nieuwe ASP.NET pagina toe aan de hoofdmap van de site met de naam Login.aspx en koppel deze aan de hoofdpagina van Site.master.

Afbeelding 8: Een nieuwe ASP.NET pagina met de naam Login.aspx toevoegen (klik om de volledige afbeelding weer te geven)

De typische interface voor de aanmeldingspagina bestaat uit twee tekstvakken: één voor de naam van de gebruiker, een voor het wachtwoord en een knop om het formulier in te dienen. Websites bevatten vaak een selectievakje 'Mij onthouden' dat, indien ingeschakeld, het resulterende verificatieticket blijft behouden tijdens het opnieuw opstarten van de browser.

Voeg twee tekstvaken toe aan Login.aspx en stel hun ID eigenschappen respectievelijk in op Gebruikersnaam en Wachtwoord. Stel ook de eigenschap Wachtwoord TextMode in op Wachtwoord. Voeg vervolgens een besturingselement Selectievakje toe, stel de ID-eigenschap in op RememberMe en de Text-eigenschap op "Remember Me". Voeg vervolgens een knop toe met de naam LoginButton waarvan Text de eigenschap is ingesteld op 'Aanmelden'. En voeg ten slotte een labelwebbesturingselement toe en stel de ID eigenschap ervan in op InvalidCredentialsMessage, de Text eigenschap ervan op 'Uw gebruikersnaam of wachtwoord is ongeldig. "Probeer het opnieuw.", en stel de ForeColor eigenschap in op rood en de Visible eigenschap in op false.

Op dit moment moet uw scherm er ongeveer als volgt uitzien als de schermafbeelding in afbeelding 9, en de declaratieve syntaxis van uw pagina moet er als volgt uitzien:

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

Afbeelding 9: De aanmeldingspagina bevat twee tekstvaken, een selectievakje, een knop en een label (klik om de volledige afbeelding weer te geven)

Maak ten slotte een event-handler voor de Click-gebeurtenis van de LoginButton. Dubbelklik eenvoudig in de Ontwerper op de Knop om deze eventhandler te maken.

Bepalen of de opgegeven referenties geldig zijn

We moeten nu taak 2 implementeren in de Klik-gebeurtenishandler van de knop. Hiermee wordt bepaald of de opgegeven inloggegevens geldig zijn. Om dit te doen, moet er een gebruikersarchief zijn dat alle referenties van de gebruikers bevat, zodat we kunnen bepalen of de opgegeven referenties overeenkomen met bekende referenties.

Vóór ASP.NET 2.0 waren ontwikkelaars verantwoordelijk voor het implementeren van zowel hun eigen gebruikersopslagplaatsen als het schrijven van de code om de verstrekte referenties tegen de opslagplaats te valideren. De meeste ontwikkelaars implementeren het gebruikersarchief in een database, waarbij een tabel met de naam Gebruikers wordt gemaakt met kolommen zoals Gebruikersnaam, Wachtwoord, E-mail, LastLoginDate, enzovoort. Deze tabel zou dan één record per gebruikersaccount hebben. Als u de opgegeven referenties van een gebruiker controleert, moet u een query uitvoeren op de database voor een overeenkomende gebruikersnaam en vervolgens controleren of het wachtwoord in de database overeenkomt met het opgegeven wachtwoord.

Met ASP.NET 2.0 moeten ontwikkelaars een van de lidmaatschapsproviders gebruiken om het gebruikersarchief te beheren. In deze reeks zelfstudies gebruiken we de SqlMembershipProvider, die gebruikmaakt van een SQL Server-database voor het gebruikersarchief. Wanneer u de SqlMembershipProvider gebruikt, moeten we een specifiek databaseschema implementeren dat de tabellen, weergaven en opgeslagen procedures bevat die door de provider worden verwacht. We gaan kijken hoe u dit schema implementeert in de zelfstudie Lidmaatschapsschema maken in SQL Server . Als de lidmaatschapsprovider is ingesteld, is het valideren van de gebruikersreferenties net zo eenvoudig als het aanroepen van de lidmaatschapsklasse's ValidateUser(gebruikersnaam, wachtwoord)-methode, die een Booleaanse waarde retourneert die aangeeft of de combinatie van gebruikersnaam en wachtwoord geldig is. Aangezien we het gebruikersarchief van SqlMembershipProvider nog niet hebben geïmplementeerd, kunnen we de methode ValidateUser van de lidmaatschapsklasse op dit moment niet gebruiken.

In plaats van de tijd te nemen om onze eigen aangepaste gebruikersdatabasetabel te bouwen (die verouderd zou zijn nadat we de SqlMembershipProvider hebben geïmplementeerd), moeten we in plaats daarvan de geldige referenties op de aanmeldingspagina zelf in code schrijven. Voeg in de Click-gebeurtenishandler van LoginButton de volgende code toe:

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

Zoals u kunt zien, zijn er drie geldige gebruikersaccounts: Scott, Jisun en Sam, en alle drie hebben hetzelfde wachtwoord ('wachtwoord'). De code doorloopt de arrays van gebruikers en wachtwoorden om te zoeken naar een geldige gebruikersnaam en wachtwoordcombinatie. Als zowel de gebruikersnaam als het wachtwoord geldig zijn, moeten we de gebruiker aanmelden en deze vervolgens omleiden naar de juiste pagina. Als de referenties ongeldig zijn, wordt het label InvalidCredentialsMessage weergegeven.

Wanneer een gebruiker geldige referenties invoert, heb ik gezegd dat ze vervolgens worden omgeleid naar de 'juiste pagina'. Wat is de juiste pagina? Wanneer een gebruiker een pagina bezoekt die hij of zij niet mag bekijken, leidt de FormsAuthenticationModule hen automatisch naar de aanmeldingspagina. Hierbij wordt de aangevraagde URL in de querystring opgenomen via de parameter ReturnUrl. Als een gebruiker probeert ProtectedPage.aspx te bezoeken en hij of zij niet gemachtigd is om dit te doen, wordt deze door de FormsAuthenticationModule omgeleid naar:

Login.aspx? ReturnUrl=ProtectedPage.aspx

Wanneer u zich hebt aangemeld, moet de gebruiker worden omgeleid naar ProtectedPage.aspx. Gebruikers kunnen de aanmeldingspagina ook zelf bezoeken. Nadat de gebruiker is ingelogd, moeten ze naar de Default.aspx-pagina van de hoofdmap worden geleid.

Gebruiker Aanmelden

Ervan uitgaande dat de opgegeven referenties geldig zijn, moeten we een formulierverificatieticket maken, waardoor de gebruiker zich bij de site aanmeldt. De klasse FormsAuthentication in de naamruimte System.Web.Security biedt verschillende methoden voor het aanmelden en afmelden van gebruikers via het formulierverificatiesysteem. Hoewel er verschillende methoden zijn in de klasse FormsAuthentication, zijn de drie waarin we geïnteresseerd zijn op dit moment:

• GetAuthCookie(gebruikersnaam, persistCookie) – maakt een formulierverificatieticket voor de opgegeven gebruikersnaam. Vervolgens wordt met deze methode een HttpCookie-object gemaakt en geretourneerd dat de inhoud van het verificatieticket bevat. Als persistentCookie waar is, wordt er een permanente cookie gemaakt.
• SetAuthCookie(gebruikersnaam, persistCookie) - roept de methode GetAuthCookie (gebruikersnaam, persistCookie) aan om de cookie voor formulierverificatie te genereren. Met deze methode wordt vervolgens de cookie die door GetAuthCookie wordt geretourneerd, toegevoegd aan de verzameling Cookies (ervan uitgaande dat verificatie van formulieren op basis van cookies wordt gebruikt; anders wordt met deze methode een interne klasse aangeroepen die de logica van het cookieloze ticket afhandelt).
• RedirectFromLoginPage(gebruikersnaam, persistCookie) - met deze methode roept u SetAuthCookie(gebruikersnaam, persistentCookie) aan en wordt de gebruiker omgeleid naar de juiste pagina.

GetAuthCookie is handig wanneer u het verificatieticket moet wijzigen voordat u de cookie naar de verzameling Cookies schrijft. SetAuthCookie is handig als u het formulierverificatieticket wilt maken en wilt toevoegen aan de verzameling Cookies, maar de gebruiker niet naar de juiste pagina wilt omleiden. Misschien wilt u ze op de aanmeldingspagina houden of naar een andere pagina verzenden.

Omdat we de gebruiker willen aanmelden en omleiden naar de juiste pagina, gaan we RedirectFromLoginPage gebruiken. Werk de Click-gebeurtenis-handler van LoginButton bij en vervang de twee TODO-opmerkingen door de volgende coderegel:

FormsAuthentication.RedirectFromLoginPage(Gebruikersnaam.Tekst, OnthoudMe.Gecontroleerd);

Bij het maken van het formulierverificatieticket gebruiken we de tekst van de UserName TextBox als de parameter gebruikersnaam voor het formulierverificatieticket en de aangevinkte status van het RememberMe-selectievakje voor de parameter persistCookie.

Als u de aanmeldingspagina wilt testen, gaat u naar de pagina in een browser. Begin met het invoeren van ongeldige referenties, zoals een gebruikersnaam van 'Nope' en een wachtwoord van 'onjuist'. Wanneer u op de aanmeldingsknop klikt, wordt er een terugpostbewerking uitgevoerd en wordt het label InvalidCredentialsMessage weergegeven.

Afbeelding 10: Het label InvalidCredentialsMessage wordt weergegeven bij het invoeren van ongeldige referenties (klik om de afbeelding op volledige grootte weer te geven)

Voer vervolgens geldige inloggegevens in en klik op de knop Inloggen. Deze keer dat de postback plaatsvindt, wordt er een formulierverificatieticket gemaakt en wordt u automatisch teruggeleid naar Default.aspx. Op dit moment hebt u zich aangemeld bij de website, hoewel er geen visuele aanwijzingen zijn om aan te geven dat u momenteel bent aangemeld. In stap 4 zien we hoe u programmatisch kunt bepalen of een gebruiker is aangemeld of niet, en hoe u de gebruiker identificeert die de pagina bezoekt.

Stap 5 onderzoekt technieken voor het uitloggen van een gebruiker van de website.

De aanmeldingspagina beveiligen

Wanneer de gebruiker haar referenties invoert en het aanmeldingspaginaformulier indient, worden de referenties , inclusief haar wachtwoord, via internet verzonden naar de webserver in tekst zonder opmaak. Dat betekent dat elke hacker die het netwerkverkeer snuffelt, de gebruikersnaam en het wachtwoord kan zien. Om dit te voorkomen, is het essentieel om het netwerkverkeer te versleutelen met behulp van SSL (Secure Socket Layers). Dit zorgt ervoor dat de referenties (evenals de HTML-markeringen van de hele pagina) worden versleuteld vanaf het moment dat ze de browser verlaten totdat ze worden ontvangen door de webserver.

Tenzij uw website gevoelige informatie bevat, hoeft u alleen SSL te gebruiken op de aanmeldingspagina en op andere pagina's waar het wachtwoord van de gebruiker anders via de kabel in tekst zonder opmaak wordt verzonden. U hoeft zich geen zorgen te maken over het beveiligen van het formulierverificatieticket, omdat het standaard zowel versleuteld als digitaal is ondertekend (om manipulatie te voorkomen). In de volgende tutorial wordt een uitgebreidere bespreking gegeven over de beveiliging van authenticatietickets in formulieren.

Opmerking

Veel financiële en medische websites zijn geconfigureerd voor het gebruik van SSL op alle pagina's die toegankelijk zijn voor geverifieerde gebruikers. Als u een dergelijke website bouwt, kunt u het formulierverificatiesysteem zo configureren dat het formulierverificatieticket alleen via een beveiligde verbinding wordt verzonden.

Stap 4: Geverifieerde bezoekers detecteren en hun identiteit bepalen

Op dit moment hebben we formulierverificatie ingeschakeld en een elementaire aanmeldingspagina gemaakt, maar we moeten nog onderzoeken hoe we kunnen bepalen of een gebruiker is geverifieerd of anoniem. In bepaalde scenario's willen we mogelijk verschillende gegevens of informatie weergeven, afhankelijk van of een geverifieerde of anonieme gebruiker de pagina bezoekt. Bovendien moeten we vaak de identiteit van de geverifieerde gebruiker kennen.

Laten we de bestaande Default.aspx pagina uitbreiden om deze technieken te illustreren. Voeg in Default.aspx twee paneelbesturingselementen toe, één met de naam AuthenticatedMessagePanel en een andere met de naam AnonymousMessagePanel. Voeg een Labelcontrole genaamd WelcomeBackMessage toe in het eerste deelvenster. In het tweede deelvenster voegt u een HyperLink-besturingselement toe, stelt u de teksteigenschap in op 'Aanmelden' en de eigenschap NavigateUrl op ~/Login.aspx. Op dit moment moet de declaratieve markering voor Default.aspx er ongeveer als volgt uitzien:

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

Zoals u waarschijnlijk al hebt geraden, is het idee om alleen de AuthenticatedMessagePanel weer te geven aan geverifieerde bezoekers en alleen de AnonymousMessagePanel aan anonieme bezoekers. Hiervoor moeten we de zichtbare eigenschappen van deze panels instellen, afhankelijk van of de gebruiker al dan niet is aangemeld.

De eigenschap Request.IsAuthenticated retourneert een Booleaanse waarde die aangeeft of de aanvraag is geverifieerd. Voer de volgende code in de Page_Load gebeurtenis-handlercode in:

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

Ga met deze code naar Default.aspx via een browser. Ervan uitgaande dat u zich nog moet aanmelden, ziet u een koppeling naar de aanmeldingspagina (zie afbeelding 11). Klik op deze koppeling en meld u aan bij de site. Zoals we in stap 3 hebben gezien, wordt u na het invoeren van uw referenties teruggezet naar Default.aspx, maar deze keer wordt op de pagina het bericht 'Welkom terug!' weergegeven (zie afbeelding 12).

Afbeelding 11: Wanneer u de site anoniem bezoekt, wordt er een aanmeldingskoppeling weergegeven

Afbeelding 12: Geverifieerde gebruikers wordt het bericht 'Welkom terug!' getoond

We kunnen de identiteit van de aangemelde gebruiker bepalen via de eigenschap User van het HttpContext-object. Het HttpContext-object vertegenwoordigt informatie over de huidige aanvraag en is de thuisbasis voor dergelijke algemene ASP.NET objecten als Antwoord, Aanvraag en Sessie, onder andere. De eigenschap Gebruiker vertegenwoordigt de beveiligingscontext van de huidige HTTP-aanvraag en implementeert de IPrincipal-interface.

De eigenschap Gebruiker wordt ingesteld door de FormsAuthenticationModule. Wanneer met de FormsAuthenticationModule een formulierverificatieticket wordt gevonden in de binnenkomende aanvraag, wordt er een nieuw GenericPrincipal-object gemaakt en aan de eigenschap Gebruiker toegewezen.

Principal-objecten (zoals GenericPrincipal) bieden informatie over de identiteit van de gebruiker en de rollen waartoe ze behoren. De IPrincipal-interface definieert twee leden:

• IsInRole(roleName): een methode die een Booleaanse waarde retourneert die aangeeft of de principal deel uitmaakt van de opgegeven rol.
• Identiteit : een eigenschap die een object retourneert dat de IIdentity-interface implementeert. De IIdentity-interface definieert drie eigenschappen: AuthenticationType, IsAuthenticated en Name.

We kunnen de naam van de huidige bezoeker bepalen met behulp van de volgende code:

string currentUsersName = User.Identity.Name; // Verkrijg de naam van de huidige gebruiker

Wanneer u formulierverificatie gebruikt, wordt een FormsIdentity-object gemaakt voor de eigenschap Identity van GenericPrincipal. De klasse FormsIdentity retourneert altijd de tekenreeks 'Forms' voor de eigenschap AuthenticationType en true voor de eigenschap IsAuthenticated. De eigenschap Naam retourneert de gebruikersnaam die is opgegeven bij het maken van het formulierverificatieticket. Naast deze drie eigenschappen bevat FormsIdentity toegang tot het onderliggende verificatieticket via de eigenschap Ticket. De eigenschap Ticket retourneert een object van het type FormsAuthenticationTicket, dat eigenschappen heeft zoals Vervaldatum, IsPersistent, IssueDate, Name, enzovoort.

Het belangrijkste punt om hier weg te nemen is dat de gebruikersnaamparameter die is opgegeven in de methoden FormsAuthEntication.GetAuthCookie(gebruikersnaam, persistentCookie), FormsAuthentication.SetAuthCookie(gebruikersnaam, persistentCookie) en FormsAuthentication.RedirectFromLoginPage(username, persistCookie) dezelfde waarde is die wordt geretourneerd door User.Identity.Name. Bovendien is het verificatieticket dat door deze methoden is gemaakt, beschikbaar door User.Identity naar een FormsIdentity-object te casten en vervolgens toegang te krijgen tot de eigenschap Ticket:

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

Laten we een persoonlijker bericht geven in Default.aspx. Werk de Page_Load gebeurtenis-handler bij zodat de eigenschap Text van het Label WelcomeBackMessage is toegewezen aan de tekenreeks 'Welkom terug, gebruikersnaam!'

WelcomeBackMessage.Text = "Welkom terug, " + User.Identity.Name + "!";

In afbeelding 13 ziet u het effect van deze wijziging (wanneer u zich aanmeldt als gebruiker Scott).

Afbeelding 13: Het welkomstbericht bevat de naam van de aangemelde gebruiker

Gebruik de componenten LoginView en LoginName

Het weergeven van verschillende inhoud voor geverifieerde en anonieme gebruikers is een algemene vereiste; geeft dus de naam weer van de momenteel aangemelde gebruiker. Daarom bevat ASP.NET twee webbesturingselementen die dezelfde functionaliteit bieden die wordt weergegeven in afbeelding 13, maar zonder dat u één regel code hoeft te schrijven.

Het besturingselement LoginView is een webbesturingselement op basis van sjablonen waarmee u eenvoudig verschillende gegevens kunt weergeven voor geverifieerde en anonieme gebruikers. De LoginView bevat twee vooraf gedefinieerde sjablonen:

• AnonymousTemplate: alle markeringen die aan deze sjabloon zijn toegevoegd, worden alleen weergegeven aan anonieme bezoekers.
• LoggedInTemplate: de opmaak van deze sjabloon wordt alleen weergegeven voor geverifieerde gebruikers.

Laten we het besturingselement LoginView toevoegen aan de basispagina van onze site, Site.master. In plaats van alleen het besturingselement LoginView toe te voegen, gaan we echter zowel een nieuw Besturingselement ContentPlaceHolder toevoegen als vervolgens het besturingselement LoginView in die nieuwe ContentPlaceHolder plaatsen. De logica voor deze beslissing zal binnenkort duidelijk worden.

Opmerking

Naast de AnonymousTemplate en LoggedInTemplate kan het besturingselement LoginView rolspecifieke sjablonen bevatten. Met rolspecifieke sjablonen worden alleen markeringen weergegeven voor gebruikers die deel uitmaken van een opgegeven rol. In een toekomstige zelfstudie bekijken we de functies op basis van rollen van het besturingselement LoginView.

Voeg eerst een ContentPlaceHolder met de naam LoginContent toe aan de basispagina binnen het navigatie <div> element. U kunt eenvoudig een ContentPlaceHolder-besturingselement vanuit de Toolbox naar de bronweergave slepen, waarbij de resulterende markup direct boven de "TODO: Menu komt hier..." tekst geplaatst wordt.

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

Voeg vervolgens een Besturingselement LoginView toe in de LoginContent ContentPlaceHolder. Inhoud die in de besturingselementen ContentPlaceHolder van de basispagina wordt geplaatst, wordt beschouwd als standaardinhoud voor de ContentPlaceHolder. Dat wil zeggen dat ASP.NET pagina's die deze basispagina gebruiken, hun eigen inhoud voor elke ContentPlaceHolder kunnen opgeven of de standaardinhoud van de basispagina kunnen gebruiken.

De besturingselementen LoginView en andere aanmeldingsgerelateerde besturingselementen bevinden zich op het tabblad Aanmelding in de Toolbox.

Afbeelding 14: Het besturingselement LoginView in de werkset

Voeg vervolgens direct na het besturingselement LoginView twee <br/> elementen toe, maar nog steeds binnen de ContentPlaceHolder. Op dit moment moet de markering van het navigatie-div-element <> er als volgt uitzien:

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

De sjablonen van LoginView kunnen worden gedefinieerd vanuit de ontwerpfunctie of de declaratieve markeringen. Vouw in Visual Studio Designer de infotag van LoginView uit, waarin de geconfigureerde sjablonen in een vervolgkeuzelijst worden vermeld. Typ de tekst 'Hallo, vreemdeling' in de AnonymousTemplate; Voeg vervolgens een HyperLink-besturingselement toe en stel de eigenschappen Text en NavigateUrl in op respectievelijk 'Log In' en '~/Login.aspx'.

Nadat u anonymousTemplate hebt geconfigureerd, schakelt u over naar de LoggedInTemplate en voert u de tekst 'Welkom terug, '' in. Sleep vervolgens een LoginName-besturingselement van de Werkset naar de LoggedInTemplate en plaats het direct na de tekst Welkom terug. Het besturingselement LoginName, zoals de naam al aangeeft, geeft de naam weer van de momenteel aangemelde gebruiker. Intern geeft het besturingselement LoginName eenvoudigweg de eigenschap User.Identity.Name weer

Nadat u deze toevoegingen hebt gemaakt aan de sjablonen van LoginView, moet de opmaak er ongeveer als volgt uitzien:

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

Met deze toevoeging aan de basispagina Site.master geeft elke pagina op onze website een ander bericht weer, afhankelijk van of de gebruiker is geverifieerd. Afbeelding 15 toont de Default.aspx pagina wanneer deze wordt bezocht via een browser door gebruiker Jisun. Het bericht 'Welkom terug, Jisun' wordt tweemaal herhaald: eenmaal in de navigatiesectie van de basispagina aan de linkerkant (via het LoginView-besturingselement dat we zojuist hebben toegevoegd) en eenmaal in het inhoudsgebied van de Default.aspx (via panelbesturingselementen en programmatische logica).

Afbeelding 15: In het besturingselement LoginView wordt 'Welkom terug, Jisun' weergegeven.

Omdat we de LoginView aan de basispagina hebben toegevoegd, kan deze op elke pagina op onze site worden weergegeven. Er kunnen echter webpagina's zijn waar we dit bericht niet willen weergeven. Een dergelijke pagina is de aanmeldingspagina, omdat een koppeling naar de aanmeldingspagina daar misplaatst lijkt. Omdat we het besturingselement LoginView in een ContentPlaceHolder op de basispagina hebben geplaatst, kunnen we deze standaardopmaak op onze inhoudspagina overschrijven. Open Login.aspx en ga naar de ontwerpfunctie. Omdat we geen inhoudsbeheer expliciet hebben gedefinieerd in Login.aspx voor de LoginContent ContentPlaceHolder op de basispagina, worden op de aanmeldingspagina de standaardmarkeringen van de basispagina weergegeven voor deze ContentPlaceHolder. U kunt dit zien via de Designer – de LoginContent-ContentPlaceHolder toont de standaard markup (de LoginView-control).

Afbeelding 16: Op de aanmeldingspagina ziet u de standaardinhoud voor de LoginContent ContentPlaceHolder van de basispagina (klik om de volledige afbeelding weer te geven)

Als u de standaardopmaak voor de LoginContent ContentPlaceHolder wilt overschrijven, klikt u met de rechtermuisknop op de regio in de ontwerpfunctie en kiest u de optie Aangepaste inhoud maken in het contextmenu. (Wanneer u Visual Studio 2008 gebruikt, bevat de ContentPlaceHolder een infolabel dat, indien geselecteerd, dezelfde optie biedt.) Hiermee voegt u een nieuw inhoudsbeheer toe aan de opmaak van de pagina en kunt u hiermee aangepaste inhoud voor deze pagina definiëren. U kunt hier een aangepast bericht toevoegen, zoals 'Meld u aan...', maar laten we dit leeg laten.

Opmerking

In Visual Studio 2005 maakt het maken van aangepaste inhoud een leeg inhoudsbeheer op de pagina ASP.NET. In Visual Studio 2008 kopieert het maken van aangepaste inhoud echter de standaardinhoud van de basispagina naar het zojuist gemaakte inhoudsbeheer. Als u Visual Studio 2008 gebruikt, moet u na het maken van het nieuwe inhoudsbeheer de gekopieerde inhoud van de basispagina wissen.

In afbeelding 17 ziet u de Login.aspx pagina wanneer deze vanuit een browser wordt bezocht nadat u deze wijziging hebt aangebracht. Houd er rekening mee dat er geen bericht 'Hallo, vreemdeling' of 'Welkom terug, gebruikersnaam' in het navigatiedeelvenster< aan de linkerkant >staat, zoals er is bij het bezoeken van Default.aspx.

Afbeelding 17: De aanmeldingspagina verbergt de standaardaantekening van LoginContent ContentPlaceHolder (klik om de volledige afbeelding weer te geven)

Stap 5: Afmelden

In stap 3 hebben we gekeken naar het bouwen van een aanmeldingspagina om een gebruiker aan te melden bij de site, maar we moeten nog zien hoe u een gebruiker afmeldt. Naast methoden voor het aanmelden van een gebruiker, biedt de klasse FormsAuthentication ook een SignOut-methode. De methode SignOut vernietigt eenvoudigweg het formulierverificatieticket, waardoor de gebruiker wordt afgemeld bij de site.

Het aanbieden van een afmeldingskoppeling is zo'n veelvoorkomende functie dat ASP.NET een besturingselement bevat dat speciaal ontworpen is om een gebruiker uit te loggen. In het besturingselement LoginStatus wordt een 'Login' LinkButton of 'Logout' LinkButton weergegeven, afhankelijk van de authenticatiestatus van de gebruiker. Er wordt een 'Login' LinkButton weergegeven voor anonieme gebruikers, terwijl een 'Afmelding' LinkButton wordt weergegeven voor geverifieerde gebruikers. De tekst voor de linkbuttons 'Login' en 'Logout' kan worden geconfigureerd via de eigenschappen LoginText en LogoutText van LoginStatus.

Als u op de 'Login'-knop klikt, zorgt dit voor een postback, waarna een omleiding naar de inlogpagina plaatsvindt. Als u op 'Afmelden' klikt, zorgt u ervoor dat het besturingselement LoginStatus de methode FormsAuthentication.SignOff aanroept en de gebruiker vervolgens omleidt naar een pagina. De pagina waarnaar de afgemelde gebruiker wordt omgeleid, is afhankelijk van de eigenschap LogoutAction, die kan worden toegewezen aan een van de volgende drie waarden:

• Vernieuwen : de standaardwaarde; de gebruiker omleidt naar de pagina die hij net bezocht. Als de pagina die ze net bezoeken geen anonieme gebruikers toestaat, stuurt de FormsAuthenticationModule de gebruiker automatisch om naar de aanmeldingspagina.

Misschien bent u benieuwd waarom hier een omleiding wordt uitgevoerd. Als de gebruiker op dezelfde pagina wil blijven staan, waarom is de expliciete omleiding dan nodig? De reden hiervoor is dat wanneer op LinkButton 'Afmelden' wordt geklikt, de gebruiker nog steeds het formulierverificatieticket in de verzameling cookies heeft. De postback-aanvraag is dus een geverifieerde aanvraag. Het besturingselement LoginStatus roept de SignOut-methode aan, maar dat gebeurt nadat de FormsAuthenticationModule de gebruiker heeft geverifieerd. Daarom zorgt een expliciete omleiding ervoor dat de browser de pagina opnieuw aanvraagt. Op het moment dat de browser de pagina opnieuw aanvraagt, is het formulierverificatieticket verwijderd en is de binnenkomende aanvraag daarom anoniem.

• Omleiding: de gebruiker wordt omgeleid naar de URL die is opgegeven door de eigenschap LogoutPageUrl van LoginStatus.
• RedirectToLoginPage: de gebruiker wordt omgeleid naar de aanmeldingspagina.

Laten we een LoginStatus-besturingselement toevoegen aan de masterpagina en deze configureren om de optie Omleiding te gebruiken. Hiermee sturen we de gebruiker naar een pagina die een bericht weergeeft ter bevestiging dat ze zijn afgemeld. Begin met het maken van een pagina genaamd Logout.aspx in de hoofdmap. Vergeet niet deze pagina te koppelen aan de basispagina site.master. Voer vervolgens een bericht in de markeringen van de pagina in waarin wordt uitgelegd dat de gebruiker is afgemeld.

Ga vervolgens terug naar de basispagina van Site.master en voeg een Besturingselement LoginStatus toe onder de LoginView in de LoginContent ContentPlaceHolder. Stel de eigenschap LogoutAction van het besturingselement LoginStatus in op Redirect en de bijbehorende eigenschap LogoutPageUrl op ~/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>

Omdat de LoginStatus zich buiten het besturingselement LoginView bevindt, wordt deze weergegeven voor zowel anonieme als geverifieerde gebruikers, maar dat is ok, omdat de LoginStatus correct een 'Login' of 'Logout' LinkButton weergeeft. Met de toevoeging van het besturingselement LoginStatus is de HyperLink 'Aanmelden' in de AnonymousTemplate overbodig, dus verwijder het.

In afbeelding 18 ziet u Default.aspx wanneer Jisun bezoekt. In de linkerkolom wordt het bericht 'Welkom terug, Jisun' weergegeven, samen met een koppeling om af te melden. Door op de afmeldkoppeling te klikken, veroorzaakt de LinkButton een postback, meldt Jisun af uit het systeem en stuurt haar vervolgens naar Logout.aspx. Zoals in afbeelding 19 wordt weergegeven, is Jisun al afgemeld tegen de tijd dat ze Logout.aspx bereikt, en is ze dus anoniem. Daarom toont de linkerkolom de tekst 'Welkom, vreemdeling' en een koppeling naar de aanmeldingspagina.

Afbeelding 18: Default.aspx toont 'Welkom terug, Jisun' samen met een 'Afmelding' LinkButton (klik om de afbeelding volledig weer te geven)

Afbeelding 19: Logout.aspx Toont 'Welkom, vreemdeling' Samen met een 'Login' LinkButton (klik om de afbeelding op volledige grootte weer te geven)

Opmerking

Ik moedig u aan om de Logout.aspx pagina aan te passen om de LoginContent ContentPlaceHolder van de basispagina te verbergen (zoals we hebben gedaan voor Login.aspx in stap 4). De reden hiervoor is dat de 'Login' LinkButton die wordt weergegeven door het besturingselement LoginStatus (degene onder de tekst "Hallo, vreemdeling") de gebruiker naar de aanmeldingspagina stuurt en de huidige URL doorgeeft in de querystring-parameter ReturnUrl. Kortom, als een gebruiker die zich heeft afgemeld, op de 'Login' LinkButton van deze LoginStatus klikt en zich vervolgens aanmeldt, wordt deze omgeleid naar Logout.aspx, wat de gebruiker gemakkelijk kan verwarren.

Samenvatting

In deze zelfstudie zijn we begonnen met een onderzoek van de werkstroom voor formulierverificatie en vervolgens omgezet in het implementeren van formulierverificatie in een ASP.NET-toepassing. Formulierverificatie wordt mogelijk gemaakt door de FormsAuthenticationModule, die twee verantwoordelijkheden heeft: gebruikers identificeren op basis van hun formulierverificatieticket en onbevoegde gebruikers omleiden naar de aanmeldingspagina.

De klasse FormsAuthentication van .NET Framework bevat methoden voor het maken, inspecteren en verwijderen van verificatietickets voor formulieren. De eigenschap Request.IsAuthenticated en het gebruikersobject bieden aanvullende programmatische ondersteuning voor het bepalen of een aanvraag is geverifieerd en informatie over de identiteit van de gebruiker. Er zijn ook de besturingselementen LoginView, LoginStatus en LoginName Web, die ontwikkelaars een snelle, codevrije manier bieden voor het uitvoeren van veel algemene aanmeldingstaken. In toekomstige zelfstudies gaan we deze en andere webbesturingselementen met betrekking tot aanmeldingen nader bekijken.

In deze handleiding wordt een beknopt overzicht gegeven van formulierverificatie. We hebben de verschillende configuratieopties niet bekeken, bekeken hoe cookieloze formulierverificatietickets werken of onderzoeken hoe ASP.NET de inhoud van het formulierverificatieticket beveiligt.

Veel plezier met programmeren!

Meer lezen

Raadpleeg de volgende bronnen voor meer informatie over de onderwerpen die in deze zelfstudie worden besproken:

• Wijzigingen tussen IIS6 en IIS7-beveiliging
• Besturingselementen voor aanmelden ASP.NET
• Professional ASP.NET 2.0 Beveiliging, Lidmaatschap en Rolbeheer (ISBN: 978-0-7645-9698-8)
• het element <authentication>
• Het <forms> element voor <authentication>

Videotraining over onderwerpen in deze tutorial

• Basisformulierverificatie gebruiken in ASP.NET

Over de auteur

Scott Mitchell, auteur van zeven ASP/ASP.NET-boeken en oprichter van 4GuysFromRolla.com, werkt sinds 1998 met Microsoft-webtechnologieën. Scott werkt als onafhankelijk consultant, trainer en schrijver. Zijn laatste boek is Sams Teach Yourself ASP.NET 2.0 in 24 uur. Hij kan worden bereikt op mitchell@4GuysFromRolla.com.

Speciaal dankzij...

Deze tutorialreeks is beoordeeld door veel behulpzame beoordelers. De hoofdrevisor voor deze zelfstudie was. Deze reeks zelfstudies is beoordeeld door veel behulpzame revisoren. Hoofdrevisoren voor deze zelfstudie zijn Alicja Maziarz, John Suru en Teresa Murphy. Bent u geïnteresseerd in het bekijken van mijn aanstaande MSDN-artikelen? Zo ja, laat iets van je horen via mitchell@4GuysFromRolla.com.

VorigeVolgende