Dela via


Skapa medlemskapsschemat i SQL Server (C#)

av Scott Mitchell

Not

Sedan den här artikeln skrevs har ASP.NET Medlemskapsleverantörer ersatts av ASP.NET Identity. Vi rekommenderar starkt att du uppdaterar appar för att använda ASP.NET Identity-plattformen i stället för medlemskapsprovidrar 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-

Den här handledningen börjar med att granska tekniker för att lägga till det nödvändiga schemat i databasen för att använda SqlMembershipProvider. Därefter går vi igenom nyckeltabellerna i schemat och diskuterar deras syfte och betydelse. Den här självstudien avslutas med en titt på hur du anger för en ASP.NET-applikation vilken leverantör som medlemskapsramverket ska använda.

Introduktion

De föregående två handledningarna undersökte användningen av formulärautentisering för att identifiera webbplatsbesökare. Ramverket för formulärautentisering gör det enkelt för utvecklare att logga in en användare på en webbplats och komma ihåg dem över sidbesök med hjälp av autentiseringsbiljetter. Klassen FormsAuthentication innehåller metoder för att generera biljetten och lägga till den i besökarens cookies. FormsAuthenticationModule undersöker alla inkommande begäranden och skapar och associerar en GenericPrincipal och ett FormsIdentity objekt med den aktuella begäran för dem med en giltig autentiseringsbegäran. Formulärautentisering är bara en mekanism för att bevilja en autentiseringsbiljett till en besökare när du loggar in och, vid efterföljande begäranden, parsa biljetten för att fastställa användarens identitet. För att ett webbprogram ska kunna stödja användarkonton måste vi fortfarande implementera ett användararkiv och lägga till funktioner för att verifiera autentiseringsuppgifter, registrera nya användare och en mängd andra användarkontorelaterade uppgifter.

Före ASP.NET 2.0 var utvecklarna ansvariga för att implementera alla uppgifter relaterade till användarkonton. Lyckligtvis identifierade ASP.NET-teamet denna brist och introducerade medlemskapsramverket med ASP.NET 2.0. Medlemskapsramverket är en uppsättning klasser i .NET Framework som tillhandahåller ett programmatiskt gränssnitt för att utföra grundläggande användarkontorelaterade uppgifter. Det här ramverket är byggt ovanpå providermodell, som gör att utvecklare kan ansluta en anpassad implementering till ett standardiserat API.

Som beskrivet i självstudiekursen Security Basics och ASP.NET Support levereras .NET Framework med två inbyggda medlemskapsleverantörer: ActiveDirectoryMembershipProvider och SqlMembershipProvider. Som namnet antyder använder SqlMembershipProvider en Microsoft SQL Server-databas som användararkiv. För att kunna använda den här providern i ett program måste vi tala om för leverantören vilken databas som ska användas som arkiv. Som du kanske föreställer dig förväntar sig SqlMembershipProvider att användarlagringsdatabasen har vissa databastabeller, vyer och lagrade procedurer. Vi måste lägga till det här förväntade schemat i den valda databasen.

Den här självstudien börjar med att undersöka tekniker för att lägga till det nödvändiga schemat i databasen så att SqlMembershipProviderkan användas. Därefter går vi igenom nyckeltabellerna i schemat och diskuterar deras syfte och betydelse. Den här självstudien avslutas med en titt på hur du instruerar en ASP.NET-applikation vilken leverantör Membership-ramverket ska använda.

Nu ska vi komma igång!

Steg 1: Bestämma var användarbutiken ska placeras

Ett ASP.NET programdata lagras ofta i ett antal tabeller i en databas. När du implementerar SqlMembershipProvider-databasschemat måste vi bestämma om medlemskapsschemat ska placeras i samma databas som programdata eller i en alternativ databas.

Jag rekommenderar att du letar upp medlemskapsschemat i samma databas som programdata av följande skäl:

  • Underhållbarhet ett program vars data är inkapslade i en databas är lättare att förstå, underhålla och distribuera än ett program som har två separata databaser.
  • Relationsintegritet genom att placera de medlemskapsrelaterade tabellerna i samma databas som programtabellerna är det möjligt att upprätta främmande-nyckelrestriktioner mellan de primära nycklarna i de medlemskapsrelaterade tabellerna och relaterade programtabeller.

Att ta bort kopplingen mellan användarlagret och programdata i separata databaser är bara meningsfullt om du har flera program som var och en använder separata databaser, men behöver dela ett gemensamt användararkiv.

Skapa en databas

Programmet som vi har byggt från och med den andra handledningen har ännu inte behövt en databas. Vi behöver en nu för användarbutiken dock. Nu ska vi skapa en och sedan lägga till det schema som krävs av SqlMembershipProvider-providern (se Steg 2).

Not

I den här självstudieserien använder vi en Microsoft SQL Server 2005 Express Edition-databas för att lagra våra programtabeller och SqlMembershipProvider schema. Det här beslutet fattades av två skäl: för det första på grund av dess kostnad – kostnadsfritt – är Express Edition den mest läsbart tillgängliga versionen av SQL Server 2005; för det andra kan SQL Server 2005 Express Edition-databaser placeras direkt i webbprogrammets App_Data mapp, vilket gör det till en cinch för att paketera databasen och webbprogrammet tillsammans i en ZIP-fil och distribuera om den utan några särskilda konfigurationsinstruktioner eller konfigurationsalternativ. Om du föredrar att följa med i en icke-Express Edition-version av SQL Server är du välkommen. Stegen är praktiskt taget identiska. Schemat SqlMembershipProvider fungerar med alla versioner av Microsoft SQL Server 2000 och senare.

Högerklicka på mappen App_Data i Solution Explorer och välj Lägg till nytt objekt. (Om du inte ser en App_Data mapp i projektet högerklickar du på projektet i Solution Explorer, väljer Lägg till ASP.NET mapp och väljer App_Data.) I dialogrutan Lägg till nytt objekt väljer du att lägga till en ny SQL Database med namnet SecurityTutorials.mdf. I den här självstudien lägger vi till schemat SqlMembershipProvider i den här databasen. i efterföljande självstudier skapar vi ytterligare tabeller för att samla in våra programdata.

Lägg till en ny SQL-databas med namnet SecurityTutorials.mdf Database i App_Data-mappen

bild 1: Lägg till en ny SQL Database med namnet SecurityTutorials.mdf Database i mappen App_Data (Klicka om du vill visa en fullstor bild)

När du lägger till en databas i mappen App_Data inkluderas den automatiskt i vyn Databasutforskaren. (I versionen av Visual Studio som inte är Express Edition kallas Databasutforskaren serverutforskaren.) Gå till Databasutforskaren och expandera den just tillagda SecurityTutorials databasen. Om du inte ser Databasutforskaren på skärmen går du till menyn Visa och väljer Databasutforskaren eller trycker på Ctrl+Alt+S. Som bild 2 visar är den SecurityTutorials databasen tom – den innehåller inga tabeller, inga vyer och inga lagrade procedurer.

SecurityTutorials-databasen är för närvarande tom

bild 2: SecurityTutorials-databasen är för närvarande tom (Klicka om du vill visa en bild i full storlek)

Steg 2: Lägga tillSqlMembershipProvider-schemat i databasen

SqlMembershipProvider kräver att en viss uppsättning tabeller, vyer och lagrade procedurer installeras i användarlagringsdatabasen. Dessa nödvändiga databasobjekt kan läggas till med hjälp av verktyget aspnet_regsql.exe. Den här filen finns i mappen %WINDIR%\Microsoft.Net\Framework\v2.0.50727\.

Anteckning

Verktyget aspnet_regsql.exe erbjuder både kommandoradsfunktioner och ett grafiskt användargränssnitt. Det grafiska gränssnittet är mer användarvänligt och är det som vi kommer att undersöka i den här handledningen. Kommandoradsgränssnittet är användbart när tillägget av SqlMembershipProvider-schemat måste automatiseras, till exempel i byggskript eller automatiserade testscenarier.

Verktyget aspnet_regsql.exe används för att lägga till eller ta bort ASP.NET programtjänster till en angiven SQL Server-databas. De ASP.NET programtjänsterna omfattar scheman för SqlMembershipProvider och SqlRoleProvider, tillsammans med scheman för SQL-baserade leverantörer för andra ASP.NET 2.0-ramverk. Vi måste tillhandahålla två bitar information till verktyget aspnet_regsql.exe:

  • Om vi vill lägga till eller ta bort programtjänster och
  • Databasen som du vill lägga till eller ta bort programtjänstschemat från

När vi uppmanar databasen att använda ber verktyget aspnet_regsql.exe oss att ange namnet på servern som databasen finns på, säkerhetsautentiseringsuppgifterna för att ansluta till databasen och databasnamnet. Om du använder den icke-Express Edition av SQL Server bör du redan känna till den här informationen eftersom det är samma information som du måste ange via en anslutningssträng när du arbetar med databasen via en ASP.NET webbsida. Att fastställa server- och databasnamnet när du använder en SQL Server 2005 Express Edition-databas i App_Data-mappen är dock lite mer involverat.

I följande avsnitt beskrivs ett enkelt sätt att ange server- och databasnamnet för en SQL Server 2005 Express Edition-databas i mappen App_Data. Om du inte använder SQL Server 2005 Express Edition kan du gå vidare till avsnittet Installera Application Services.

Fastställa server- och databasnamnet för en SQL Server 2005 Express Edition-databas i mappenApp_Data

För att kunna använda verktyget aspnet_regsql.exe behöver vi känna till server- och databasnamnen. Servernamnet är localhost\InstanceName. Förmodligen är InstanceNameSQLExpress. Men om du installerade SQL Server 2005 Express Edition manuellt (det vill säga att du inte installerade det automatiskt när du installerade Visual Studio) är det möjligt att du valde ett annat instansnamn.

Databasnamnet är lite svårare att avgöra. Databaser i mappen App_Data har vanligtvis ett databasnamn som innehåller en globalt unik identifierare tillsammans med sökvägen till databasfilen. Vi måste fastställa det här databasnamnet för att kunna lägga till programtjänstschemat via aspnet_regsql.exe.

Det enklaste sättet att fastställa databasnamnet är att undersöka det via SQL Server Management Studio. SQL Server Management Studio tillhandahåller ett grafiskt gränssnitt för hantering av SQL Server 2005-databaser, men det levereras inte med Express Edition av SQL Server 2005. Den goda nyheten är att du kan ladda ner Express Edition-versionen av SQL Server Management Studio utan kostnad.

Anteckning

Om du också har en icke-Express Edition-version av SQL Server 2005 installerad på skrivbordet installeras troligen den fullständiga versionen av Management Studio. Du kan använda den fullständiga versionen för att fastställa databasnamnet genom att följa samma steg som beskrivs nedan för Express Edition.

Börja med att stänga Visual Studio för att se till att alla lås som har införts av Visual Studio på databasfilen stängs. Starta sedan SQL Server Management Studio och anslut till localhost\InstanceName-databasen för SQL Server 2005 Express Edition. Som tidigare nämnts är risken stor att instansnamnet är SQLExpress. För alternativet Autentisering väljer du Windows-autentisering.

Anslut till SQL Server 2005 Express Edition-instansen

bild 3: Anslut till SQL Server 2005 Express Edition-instansen (Klicka om du vill visa en fullstor bild)

När du har anslutit till SQL Server 2005 Express Edition-instansen visar Management Studio mappar för databaser, säkerhetsinställningar, serverobjekt och så vidare. Om du expanderar fliken Databaser ser du att databasen SecurityTutorials.mdf är inte registrerad i databasinstansen – vi måste ansluta databasen först.

Högerklicka på mappen Databaser och välj Bifoga på snabbmenyn. Då visas dialogrutan Bifoga databaser. Härifrån klickar du på knappen Lägg till, bläddrar till databasen SecurityTutorials.mdf och klickar på OK. Bild 4 visar dialogrutan Bifoga databaser när SecurityTutorials.mdf databas har valts. Bild 5 visar Management Studio Object Explorer när databasen har kopplats.

Anslut SecurityTutorials.mdf-databas

bild 4: Bifoga SecurityTutorials.mdf-databasen (Klicka om du vill visa en bild i full storlek)

SecurityTutorials.mdf-databasen visas i mappen Databaser

bild 5: Databasen SecurityTutorials.mdf visas i mappen Databaser (Klicka om du vill visa en bild i full storlek)

Som bild 5 visar har SecurityTutorials.mdf-databasen ett ganska komplicerat namn. Nu ska vi ändra det till ett mer minnesvärt (och enklare att skriva) namn. Högerklicka på databasen, välj Byt namn på snabbmenyn och byt namn på den SecurityTutorialsDatabase. Detta ändrar inte filnamnet, bara namnet som databasen använder för att identifiera sig för SQL Server.

Byt namn på databasen till SecurityTutorialsDatabase

bild 6: Byt namn på databasen till SecurityTutorialsDatabase(Klicka om du vill visa en bild i full storlek)

Nu känner vi till server- och databasnamnen för SecurityTutorials.mdf-databasfilen: localhost\InstanceName respektive SecurityTutorialsDatabase. Nu är vi redo att installera programtjänsterna via verktyget aspnet_regsql.exe.

Installera applikationstjänster

Om du vill starta verktyget aspnet_regsql.exe går du till Start-menyn och väljer Kör. Ange %WINDIR%\Microsoft.Net\Framework\v2.0.50727\aspnet_regsql.exe i textrutan och klicka på OK. Du kan också använda Utforskaren för att öka detaljnivån till lämplig mapp och dubbelklicka på filen aspnet_regsql.exe. Båda metoderna ger samma resultat.

Om du kör aspnet_regsql.exe-verktyget utan kommandoradsargument startas det grafiska användargränssnittet ASP.NET SQL Server-installationsguiden. Guiden gör det enkelt att lägga till eller ta bort ASP.NET programtjänster på en angiven databas. Den första skärmen i guiden, som visas i bild 7, beskriver syftet med verktyget.

Använd installationsguiden för ASP.NET SQL Server för att lägga till medlemskapsschemat

bild 7: Använd installationsguiden för ASP.NET SQL Server för att lägga till medlemskapsschemat (Klicka om du vill visa en bild i full storlek)

Det andra steget i guiden frågar oss om vi vill lägga till programtjänsterna eller ta bort dem. Eftersom vi vill lägga till tabeller, vyer och lagrade procedurer som krävs för SqlMembershipProviderväljer du alternativet Konfigurera SQL Server för programtjänster. Om du senare vill ta bort det här schemat från databasen kör du guiden igen, men väljer i stället alternativet Ta bort programtjänstinformation från en befintlig databas.

Välj alternativet Konfigurera SQL Server för Application Services

bild 8: Välj alternativet Konfigurera SQL Server för Application Services (Klicka om du vill visa en bild i full storlek)

Det tredje steget frågar efter databasinformationen: servernamnet, autentiseringsinformationen och databasnamnet. Om du har följt den här självstudien och har lagt till SecurityTutorials.mdf-databasen i App_Data, kopplat den till localhost\InstanceNameoch bytt namn på den till SecurityTutorialsDatabase, använder du följande värden:

  • Server: localhost\InstanceName
  • Windows-autentisering
  • Databas: SecurityTutorialsDatabase

Ange databasinformationen

bild 9: Ange databasinformationen (Klicka om du vill visa en bild i full storlek)

När du har angett databasinformationen klickar du på Nästa. Det sista steget sammanfattar de steg som ska vidtas. Klicka på Nästa för att installera programtjänsterna och klicka sedan på Slutför för att avsluta guiden.

Not

Om du använde Management Studio för att bifoga databasen och byta namn på databasfilen måste du koppla från databasen och stänga Management Studio innan du öppnar Visual Studio igen. Om du vill koppla från databasen SecurityTutorialsDatabase högerklickar du på databasnamnet och väljer Koppla från i menyn Uppgifter.

När guiden är klar går du tillbaka till Visual Studio och navigerar till Databasutforskaren. Expandera mappen Tabeller. Du bör se en serie tabeller vars namn börjar med prefixet aspnet_. På samma sätt finns en mängd olika vyer och lagrade procedurer under mapparna Vyer och Lagrade procedurer. Dessa databasobjekt utgör programtjänstschemat. Vi kommer att undersöka de medlemskaps- och rollspecifika databasobjekten i steg 3.

En mängd olika tabeller, vyer och lagrade procedurer har lagts till i databasen

bild 10: En mängd olika tabeller, vyer och lagrade procedurer har lagts till i databasen (Klicka om du vill visa en bild i full storlek)

Not

aspnet_regsql.exe-verktygets grafiska användargränssnitt installerar hela programtjänstschemat. Men när du kör aspnet_regsql.exe från kommandoraden kan du ange vilka specifika programtjänstkomponenter som ska installeras (eller ta bort). Kör därför aspnet_regsql.exe från kommandoraden om du bara vill lägga till de tabeller, vyer och lagrade procedurer som krävs för SqlMembershipProvider- och SqlRoleProvider providrar. Du kan också manuellt köra rätt delmängd av T-SQL-skapa-skript som används av aspnet_regsql.exe. Dessa skript finns i mappen WINDIR%\Microsoft.Net\Framework\v2.0.50727\ med namn som InstallCommon.sql,InstallMembership.sql,InstallRoles.sql, InstallProfile.sql,InstallSqlState.sqloch så vidare.

Nu har vi skapat de databasobjekt som behövs av SqlMembershipProvider. Vi måste dock fortfarande instruera medlemskapsramverket att det ska använda SqlMembershipProvider (jämfört med ActiveDirectoryMembershipProvider) och att SqlMembershipProvider ska använda SecurityTutorials-databasen. Vi ska titta på hur du anger vilken provider som ska användas och hur du anpassar den valda providerns inställningar i steg 4. Men först ska vi titta närmare på databasobjekten som just har skapats.

Steg 3: En titt på schemats kärntabeller

När du arbetar med ramverken medlemskap och roller i ett ASP.NET program kapslas implementeringsinformationen in av providern. I framtida självstudier kommer vi att samverka med dessa ramverk via .NET Frameworks Membership- och Roles-klasser. När vi använder dessa högnivå-API:er behöver vi inte bry oss om informationen på låg nivå, till exempel vilka frågor som körs eller vilka tabeller som ändras av SqlMembershipProvider och SqlRoleProvider.

Med tanke på detta kan vi använda ramverken medlemskap och roller utan att ha utforskat databasschemat som skapades i steg 2. Men när du skapar tabellerna för att lagra programdata kan vi behöva skapa entiteter som är relaterade till användare eller roller. Det hjälper dig att känna till scheman för SqlMembershipProvider och SqlRoleProvider när du upprättar begränsningar för sekundärnyckel mellan programdatatabellerna och de tabeller som skapades i steg 2. I vissa sällsynta fall kan vi dessutom behöva interagera med användar- och rollarkiven direkt på databasnivå (i stället för via Membership- eller Roles-klasserna).

Partitionera användarlagret i program

Medlemskaps- och rollramverken är utformade så att den enskilda användaren och rollförrådet kan delas av många olika program. Ett ASP.NET program som använder ramverken Medlemskap eller Roller måste ange vilken programpartition som ska användas. Kort och kort kan flera webbprogram använda samma användar- och rolllager. Bild 11 visar användar- och rolllager som är partitionerade i tre program: HRSite, CustomerSite och SalesSite. Dessa tre webbprogram har sina egna unika användare och roller, men de lagrar alla fysiskt sina användarkonton och rollinformation i samma databastabeller.

användarkonton kan partitioneras i flera program

bild 11: Användarkonton kan partitioneras över flera program (Klicka om du vill visa en bild i full storlek)

Tabellen aspnet_Applications definierar dessa partitioner. Varje program som använder databasen för att lagra användarkontoinformation representeras av en rad i den här tabellen. Tabellen aspnet_Applications har fyra kolumner: ApplicationId, ApplicationName, LoweredApplicationNameoch Description. ApplicationId är av typen uniqueidentifier och är tabellens primära nyckel. ApplicationName ger varje program ett unikt människovänligt namn.

De andra medlemskaps- och rollrelaterade tabellerna länkar tillbaka till fältet ApplicationId i aspnet_Applications. Till exempel har tabellen aspnet_Users, som innehåller en post för varje användarkonto, ett ApplicationId främmande nyckelfält. Ditto för tabellen aspnet_Roles. Fältet ApplicationId i dessa tabeller anger den programpartition som användarkontot eller rollen tillhör.

Lagra information om användarkonto

Användarkontoinformation finns i två tabeller: aspnet_Users och aspnet_Membership. Tabellen aspnet_Users innehåller fält som innehåller viktig information om användarkontot. De tre mest relevanta kolumnerna är:

  • UserId
  • UserName
  • ApplicationId

UserId är primärnyckeln (och av typen uniqueidentifier). UserName är av typen nvarchar(256) och utgör tillsammans med lösenordet användarens autentiseringsuppgifter. (En användares lösenord lagras i tabellen aspnet_Membership.) ApplicationId länkar användarkontot till ett visst program i aspnet_Applications. Det finns en sammansatt UNIQUE begränsning för kolumnerna UserName och ApplicationId. Detta säkerställer att varje Användarnamn i ett visst program är unikt, men tillåter att samma UserName används i olika program.

Tabellen aspnet_Membership innehåller ytterligare information om användarkonton, t.ex. användarens lösenord, e-postadress, senaste inloggningsdatum och -tid och så vidare. Det finns en en-till-en-korrespondens mellan poster i tabellerna aspnet_Users och aspnet_Membership. Den här relationen säkerställs av fältet UserId i aspnet_Membership, som fungerar som tabellens primära nyckel. Precis som i tabellen aspnet_Users innehåller aspnet_Membership ett ApplicationId fält som kopplar den här informationen till en viss programpartition.

Skydda lösenord

Lösenordsinformation lagras i tabellen aspnet_Membership. Med SqlMembershipProvider kan lösenord lagras i databasen med någon av följande tre tekniker:

  • Rensa – lösenordet lagras i databasen som oformaterad text. Jag avråder starkt från att använda det här alternativet. Om databasen komprometteras - oavsett om det är en hackare som hittar en bakdörr eller en missnöjd anställd som har databasåtkomst - finns varje enskild användares autentiseringsuppgifter där för tagandet.
  • Hashed – lösenord hashas med en enkelriktad hashalgoritm och ett slumpmässigt genererat saltvärde. Det här hashvärdet (tillsammans med saltet) lagras i databasen.
  • Krypterad – en krypterad version av lösenordet lagras i databasen.

Vilken teknik för lösenordslagring som används beror på de SqlMembershipProvider inställningar som anges i Web.config. Vi ska titta på hur du anpassar inställningarna för SqlMembershipProvider i steg 4. Standardbeteendet är att lagra lösenordets hash.

De kolumner som ansvarar för att lagra lösenordet är Password, PasswordFormatoch PasswordSalt. PasswordFormat är ett fält av typen int vars värde anger vilken teknik som används för att lagra lösenordet: 0 för Clear; 1 för Hashed; 2 för Krypterad. PasswordSalt tilldelas en slumpmässigt genererad sträng oavsett vilken teknik för lösenordslagring som används. värdet för PasswordSalt används endast vid beräkning av lösenordets hash. Slutligen innehåller kolumnen Password faktiska lösenordsdata, oavsett om det är lösenordet i klartext, lösenordets hash eller det krypterade lösenordet.

Tabell 1 illustrerar hur dessa tre kolumner kan se ut för de olika lagringsteknikerna när du lagrar lösenordet MySecret! .

Lagringsteknik<_o3a_p/> Lösenord<_o3a_p/> PasswordFormat<_o3a_p/> PasswordSalt<_o3a_p/>
Klar MySecret! 0 tTnkPlesqissc2y2SMEygA==
Hasherad 2oXm6sZHWbTHFgjgkGQsc2Ec9ZM= 1 wFgjUfhdUFOCKQiI61vtiQ==
Krypterade 62RZgDvhxykkqsMchZ0Yly7HS6onhpaoCYaRxV8g0F4CW56OXUU3e7Inza9j9BKp 2 LSRzhGS/aa/oqAXGLHJNBw==

Tabell 1: Exempelvärden för Password-Related-fälten när lösenordet MySecret! lagras.

Anteckning

Den specifika krypterings- eller hashalgoritmen som används av SqlMembershipProvider bestäms av inställningarna i <machineKey>-elementet.

Lagra roller och rollassociationer

Med ramverket Roller kan utvecklare definiera en uppsättning roller och ange vilka användare som tillhör vilka roller. Den här informationen samlas in i databasen via två tabeller: aspnet_Roles och aspnet_UsersInRoles. Varje post i tabellen aspnet_Roles representerar en roll för ett visst program. Precis som den aspnet_Users tabellen har tabellen aspnet_Roles tre kolumner som är relevanta för vår diskussion:

  • RoleId
  • RoleName
  • ApplicationId

RoleId är primärnyckeln (och av typen uniqueidentifier). RoleName är av typen nvarchar(256). Och ApplicationId länkar användarkontot till ett visst program i aspnet_Applications. Det finns en sammansatt UNIQUE begränsning för kolumnerna RoleName och ApplicationId, vilket säkerställer att varje rollnamn är unikt i ett visst program.

Tabellen aspnet_UsersInRoles fungerar som en mappning mellan användare och roller. Det finns bara två kolumner – UserId och RoleId – och tillsammans utgör de en sammansatt primärnyckel.

Steg 4: Ange providern och anpassa dess inställningar

Alla ramverk som stöder providermodellen – till exempel ramverken medlemskap och roller – saknar själva implementeringsinformationen och delegerar i stället ansvaret till en providerklass. När det gäller ramverket Medlemskap definierar klassen Membership API:et för att hantera användarkonton, men den interagerar inte direkt med någon användardatabas. I stället lämnar Membership-klassens metoder bort begäran till den konfigurerade providern – vi använder SqlMembershipProvider. Hur vet medlemskapsramverket att delegera anropet till SqlMembershipProvidernär vi invokerar en av metoderna i Membership-klassen?

Klassen Membership har en Providers egenskap som innehåller en referens till alla registrerade leverantörsklasser som är tillgängliga för användning inom medlemskapsramen. Varje registrerad provider har ett associerat namn och en typ. Namnet erbjuder ett människovänligt sätt att referera till en viss provider i Providers samling, medan typen identifierar providerklassen. Dessutom kan varje registrerad provider innehålla konfigurationsinställningar. Konfigurationsinställningar för medlemskapsramverket omfattar bland annat passwordFormat och requiresUniqueEmail. Se Tabell 2 för en fullständig lista över konfigurationsinställningar som används av SqlMembershipProvider.

Innehållet i den Providers egenskapen anges via webbprogrammets konfigurationsinställningar. Som standard har alla webbprogram en provider med namnet AspNetSqlMembershipProvider av typen SqlMembershipProvider. Den här standardmedlemskapsprovidern är registrerad i machine.config (finns på %WINDIR%\Microsoft.Net\Framework\v2.0.50727\CONFIG):

Varning

Det verkar som om exemplet du letar efter har flyttats! Var säker på att vi arbetar med att lösa detta.

Som pålägget ovan visar definierar <membership>-elementet konfigurationsinställningarna för medlemskapsramverket medan det <providers> underordnade elementet anger registrerade providers. Leverantörer kan läggas till eller tas bort med hjälp av elementen <add> eller <remove>. använd elementet <clear> för att ta bort alla registrerade leverantörer. Som markup-koden ovan visar, lägger machine.config till en leverantör med namnet AspNetSqlMembershipProvider av typen SqlMembershipProvider.

Förutom attributen name och type innehåller elementet <add> attribut som definierar värdena för olika konfigurationsinställningar. Tabell 2 visar tillgängliga SqlMembershipProvider-specifika konfigurationsinställningar, tillsammans med en beskrivning av var och en.

Not

Standardvärden som anges i tabell 2 refererar till standardvärdena som definierats i klassen SqlMembershipProvider. Observera att inte alla konfigurationsinställningar i AspNetSqlMembershipProvider motsvarar standardvärdena för klassen SqlMembershipProvider. Om det till exempel inte anges i en medlemskapsprovider är inställningen requiresUniqueEmail som standard true. Men AspNetSqlMembershipProvider åsidosätter det här standardvärdet genom att uttryckligen ange värdet false.

inställning<_o3a_p /> Beskrivning<_o3a_p />
ApplicationName Kom ihåg att medlemskapsramverket gör att ett enda användararkiv kan partitioneras i flera program. Den här inställningen anger namnet på programpartitionen som används av medlemskapsprovidern. Om det här värdet inte uttryckligen anges, sätts det under körning till värdet för programmets virtuella rotsökväg.
commandTimeout Anger sql-kommandots timeout-värde (i sekunder). Standardvärdet är 30.
connectionStringName Namnet på anslutningssträngen i <connectionStrings>-elementet som ska användas för att ansluta till användarlagringsdatabasen. Det här värdet krävs.
description Ger en människovänlig beskrivning av den registrerade providern.
enablePasswordRetrieval Anger om användarna kan hämta sitt bortglömda lösenord. Standardvärdet är false.
enablePasswordReset Anger om användarna får återställa sitt lösenord. Standardvärdet är true.
maxInvalidPasswordAttempts Det maximala antalet misslyckade inloggningsförsök som kan inträffa för en viss användare under den angivna passwordAttemptWindow innan användaren låses ut. Standardvärdet är 5.
minRequiredNonalphanumericCharacters Det minsta antalet icke-alfanumeriska tecken som måste visas i en användares lösenord. Det här värdet måste vara mellan 0 och 128. standardvärdet är 1.
minRequiredPasswordLength Det minsta antal tecken som krävs i ett lösenord. Det här värdet måste vara mellan 0 och 128. standardvärdet är 7.
name Namnet på den registrerade providern. Det här värdet krävs.
passwordAttemptWindow Antalet minuter under vilka misslyckade inloggningsförsök spåras. Om en användare anger ogiltiga inloggningsuppgifter maxInvalidPasswordAttempts gånger i det här angivna fönstret är de utelåst. Standardvärdet är 10.
PasswordFormat Formatet för lösenordslagring: Clear, Hashedeller Encrypted. Standardvärdet är Hashed.
passwordStrengthRegularExpression Om det tillhandahålls används det här reguljära uttrycket för att utvärdera styrkan hos användarens valda lösenord när du skapar ett nytt konto eller när de ändrar sitt lösenord. Standardvärdet är en tom sträng.
requiresQuestionAndAnswer Anger om en användare måste besvara sin säkerhetsfråga när han eller hon hämtar eller återställer sitt lösenord. Standardvärdet är true.
requiresUniqueEmail Anger om alla användarkonton i en viss programpartition måste ha en unik e-postadress. Standardvärdet är true.
type Anger leverantörens typ. Det här värdet krävs.

Tabell 2: Konfigurationsinställningar för medlemskap och SqlMembershipProvider

Förutom AspNetSqlMembershipProviderkan andra Membership-leverantörer registreras per applikation genom att lägga till liknande kod i Web.config-filen.

Notera

Rollramverket fungerar på ungefär samma sätt: det finns en standardregistrerad rollprovider i machine.config och de registrerade leverantörerna kan anpassas program för program i Web.config. Vi kommer att granska rollenramen och dess konfigurationsmall i detalj i en framtida handledning.

Anpassa inställningarna förSqlMembershipProvider

Standardattributet SqlMembershipProvider (AspNetSqlMembershipProvider) har värdet connectionStringNameLocalSqlServer. Precis som AspNetSqlMembershipProvider-providern definieras namnet på anslutningssträngen LocalSqlServer i machine.config.

Varning

Det verkar som om exemplet du letar efter har flyttats! Var säker på att vi arbetar med att lösa detta.

Som du ser definierar den här anslutningssträngen en SQL 2005 Express Edition-databas som finns på |DataDirectory|aspnetdb.mdf'. Strängen |DataDirectory| översätts vid körning för att peka på katalogen ~/App_Data/, så databassökvägen |DataDirectory|aspnetdb.mdf" översätts till ~/App_Data/aspnet.mdf.

Om vi inte angav någon information om medlemskapsprovidern i programmets Web.config-fil använder programmet standardregistrerad medlemskapsprovider AspNetSqlMembershipProvider. Om den ~/App_Data/aspnet.mdf databasen inte finns skapar ASP.NET-körningen den automatiskt och lägger till schemat för programtjänster. Vi vill dock inte använda aspnet.mdf-databasen. I stället vill vi använda den SecurityTutorials.mdf databas som vi skapade i steg 2. Den här ändringen kan utföras på något av två sätt:

  • Ange ett värde förLocalSqlServeranslutningssträngens namn iWeb.config. Genom att skriva över värdet för LocalSqlServer anslutningssträngsnamn i Web.configkan vi använda standardregistrerad medlemskapsprovider (AspNetSqlMembershipProvider) och få den att fungera korrekt med SecurityTutorials.mdf-databasen. Den här metoden fungerar bra om du är nöjd med de konfigurationsinställningar som anges av AspNetSqlMembershipProvider. Mer information om den här tekniken finns i Scott Guthrieblogginlägg Konfigurera ASP.NET 2.0 Application Services att använda SQL Server 2000 eller SQL Server 2005.
  • Lägg till en ny registrerad provider av typenSqlMembershipProvideroch konfigurera dess inställning förconnectionStringNameså att den pekar påSecurityTutorials.mdf-databasen. Den här metoden är användbar i scenarier där du vill anpassa andra konfigurationsegenskaper utöver databasanslutningssträngen. I mina egna projekt använder jag alltid den här metoden på grund av dess flexibilitet och läsbarhet.

Innan vi kan lägga till en ny registrerad provider som refererar till SecurityTutorials.mdf-databasen måste vi först lägga till ett lämpligt anslutningssträngsvärde i avsnittet <connectionStrings> i Web.config. Följande markering lägger till en ny anslutningssträng med namnet SecurityTutorialsConnectionString som refererar till SQL Server 2005 Express Edition SecurityTutorials.mdf-databasen i mappen App_Data.

Varning

Det verkar som om exemplet du letar efter har flyttats! Var säker på att vi arbetar med att lösa detta.

Notera

Om du använder en alternativ databasfil uppdaterar du anslutningssträngen efter behov. Mer information om hur du bildar rätt anslutningssträng finns i ConnectionStrings.com.

Lägg sedan till följande medlemskapskonfiguration markup i filen Web.config. Den här koden registrerar en ny leverantör med namnet SecurityTutorialsSqlMembershipProvider.

Varning

Det verkar som om exemplet du letar efter har flyttats! Var säker på att vi arbetar med att lösa detta.

Förutom att registrera SecurityTutorialsSqlMembershipProvider-providern definierar ovanstående markering SecurityTutorialsSqlMembershipProvider som standardprovider (via attributet defaultProvider i elementet <membership>). Kom ihåg att medlemskapsramverket kan ha flera registrerade leverantörer. Eftersom AspNetSqlMembershipProvider är registrerad som den första providern i machine.configfungerar den som standardprovider om vi inte anger något annat.

För närvarande har vårt program två registrerade leverantörer: AspNetSqlMembershipProvider och SecurityTutorialsSqlMembershipProvider. Innan vi registrerade SecurityTutorialsSqlMembershipProvider-providern kunde vi dock ha rensat ut alla tidigare registrerade leverantörer genom att lägga till ett <clear /> element omedelbart före vårt <add>-element. Detta skulle rensa ut AspNetSqlMembershipProvider från listan över registrerade leverantörer, vilket innebär att SecurityTutorialsSqlMembershipProvider skulle vara den enda registrerade medlemskapsprovidern. Om vi använde den här metoden skulle vi inte behöva markera SecurityTutorialsSqlMembershipProvider som standardprovider, eftersom det skulle vara den enda registrerade medlemskapsprovidern. För mer information om hur du använder <clear />, se Använda <clear /> När du lägger till leverantörer.

Observera att inställningen för SecurityTutorialsSqlMembershipProvider:s connectionStringName refererar till det SecurityTutorialsConnectionString anslutningssträngsnamn som just lagts till och att inställningen för dess applicationName har angetts till värdet SecurityTutorials. Dessutom har inställningen requiresUniqueEmail angetts till true. Alla andra konfigurationsalternativ är identiska med värdena i AspNetSqlMembershipProvider. Gör gärna några konfigurationsändringar här, om du vill. Du kan till exempel öka lösenordsstyrkan genom att kräva två icke-alfanumeriska tecken i stället för ett, eller genom att öka lösenordslängden till åtta tecken i stället för sju.

Not

Kom ihåg att medlemskapsramverket gör att ett enda användararkiv kan partitioneras i flera program. Medlemskapsleverantörens applicationName-inställning anger vilken applikation providern använder när den arbetar med användarlagret. Det är viktigt att du uttryckligen anger ett värde för konfigurationsinställningen applicationName eftersom om applicationName inte uttryckligen har angetts tilldelas den till webbprogrammets virtuella rotsökväg vid körning. Detta fungerar bra så länge programmets virtuella rotsökväg inte ändras, men om du flyttar programmet till en annan sökväg ändras även inställningen för applicationName. När detta inträffar börjar medlemskapsprovidern arbeta med en annan programpartition än vad som tidigare användes. Användarkonton som skapades före flytten finns i en annan programpartition och dessa användare kommer inte längre att kunna logga in på webbplatsen. För en mer ingående diskussion om denna fråga, se Ställ alltid in applicationName-egenskapen vid konfiguration av ASP.NET 2.0-medlemskap och andra leverantörer.

Sammanfattning

Nu har vi en databas med de konfigurerade programtjänsterna (SecurityTutorials.mdf) och har konfigurerat vårt webbprogram så att medlemskapsramverket använder den SecurityTutorialsSqlMembershipProvider provider som vi nyss registrerade. Den här registrerade providern är av typen SqlMembershipProvider och har sin connectionStringName inställd på lämplig anslutningssträng (SecurityTutorialsConnectionString) och dess applicationName värde anges uttryckligen.

Nu är vi redo att använda medlemskapsramverket från vårt program. I nästa handledning kommer vi att undersöka hur du skapar nya användarkonton. Därefter utforskar vi autentisering av användare, utför användarbaserad auktorisering och lagrar ytterligare användarrelaterad information i databasen.

Lycklig programmering!

Ytterligare läsning

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

Videoutbildning om ämnen som finns i denna handledning

Om författaren

Scott Mitchell, författare till flera 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. Scott kan nås på mitchell@4guysfromrolla.com eller via sin blogg på http://ScottOnWriting.NET.

Särskilt tack till

Den här självstudieserien granskades av många användbara granskare. Ansvarig granskare för den här handledningen var Alicja Maziarz. Vill du granska mina kommande MSDN-artiklar? Hör av dig på mitchell@4GuysFromRolla.com.