A tagsági séma létrehozása az SQL Serverben (C#)

készítette: Scott Mitchell

Kód letöltése vagy PDF- letöltése

Ez az oktatóanyag az SqlMembershipProvider használatához szükséges séma adatbázishoz való hozzáadásához szükséges technikák vizsgálatával kezdődik. Ezt követően megvizsgáljuk a séma kulcstábláját, és megvitatjuk azok célját és fontosságát. Ez az oktatóanyag azzal zárul, hogy miként lehet egy ASP.NET alkalmazásnak megadni, melyik szolgáltatót használja a Membership keretrendszer.

Az előző két oktatóanyag űrlap-hitelesítéssel vizsgálta meg a webhely látogatóinak azonosítását. Az űrlaphitelesítési keretrendszer segítségével a fejlesztők egyszerűen bejelentkezhetnek egy felhasználót egy webhelyre, és a hitelesítési jegyek használatával emlékezhetnek rájuk az oldallátogatások során. A FormsAuthentication osztály metódusokat tartalmaz a jegy létrehozásához és a látogató cookie-khoz való hozzáadásához. A FormsAuthenticationModule megvizsgálja az összes bejövő kérést, és az érvényes hitelesítési jegyekkel rendelkezők számára létrehoz és társít egy GenericPrincipal és egy FormsIdentity objektumot az aktuális kéréssel. Az űrlapalapú hitelesítés csupán egy olyan mechanizmus, amely hitelesítési jegyet ad a látogatónak bejelentkezéskor, és a későbbi kérések során elemzi a jegyet a felhasználó identitásának meghatározásához. Ahhoz, hogy egy webalkalmazás támogassa a felhasználói fiókokat, továbbra is létre kell hoznunk egy felhasználói tárat, és funkciókat kell hozzáadnunk a hitelesítő adatok ellenőrzéséhez, új felhasználók regisztrálásához és a felhasználói fiókokhoz kapcsolódó feladatok számtalan eleméhez.

A 2.0-s ASP.NET előtt a fejlesztők feladatuk volt minden felhasználói fiókokkal kapcsolatos feladatot megvalósítani. Szerencsére a ASP.NET csapat felismerte ezt a hiányosságot, és bevezette a tagsági keretrendszert a ASP.NET 2.0-val. A tagsági keretrendszer a .NET-keretrendszer olyan osztályai, amelyek programozott felületet biztosítanak az alapvető felhasználói fiókokhoz kapcsolódó feladatok elvégzéséhez. Ez a keretrendszer a szolgáltatói modellalapul, amely lehetővé teszi, hogy a fejlesztők testre szabott implementációt csatlakoztassanak egy szabványosított API-hoz.

Ahogy az Biztonsági alapismeretek és az ASP.NET támogatás oktatóanyag ismerteti, a .NET keretrendszer két beépített tagsági szolgáltatóval rendelkezik: ActiveDirectoryMembershipProvider és SqlMembershipProvider. Ahogy a neve is mutatja, a SqlMembershipProvider egy Microsoft SQL Server-adatbázist használ felhasználói tárolóként. Ahhoz, hogy ezt a szolgáltatót egy alkalmazásban használhassa, meg kell adnunk a szolgáltatónak, hogy milyen adatbázist használjon tárolóként. Tegyük fel, hogy a SqlMembershipProvider arra számít, hogy a felhasználói tároló adatbázisa rendelkezik bizonyos adatbázistáblákkal, nézetekkel és tárolt eljárásokkal. Ezt a várt sémát hozzá kell adnunk a kiválasztott adatbázishoz.

Ez az oktatóanyag a szükséges séma adatbázishoz való hozzáadásának technikáinak vizsgálatával kezdődik a SqlMembershipProviderhasználatához. Ezt követően megvizsgáljuk a séma kulcstábláját, és megvitatjuk azok célját és fontosságát. Ez az oktatóanyag úgy fejeződik be, hogy áttekintjük, hogyan lehet egy ASP.NET alkalmazásnak megadni, melyik szolgáltatót használja a tagsági rendszer.

Lássunk hozzá!

Az ASP.NET-alkalmazások adatait gyakran egy adatbázis több táblájában tárolják. A SqlMembershipProvider adatbázisséma megvalósításakor el kell döntenünk, hogy a tagsági sémát ugyanabban az adatbázisban helyezik-e el, mint az alkalmazás adatai, vagy egy másik adatbázisban.

A tagsági sémát az alábbi okokból ajánlom ugyanabban az adatbázisban, mint az alkalmazás adatai:

• Karbantarthatóság egy olyan alkalmazás, amelynek adatai egy adatbázisban vannak beágyazva, könnyebben érthető, karbantartható és üzembe helyezhető, mint egy két különálló adatbázissal rendelkező alkalmazás.
• Relációs integritás ' azáltal, hogy a tagsággal kapcsolatos táblákat az alkalmazástáblákkal azonos adatbázisban helyezzük el, lehetőség van külső kulcs megszorítások létrehozására a tagságtáblák és a hozzájuk kapcsolódó alkalmazástáblák elsődleges kulcsai között.

A felhasználói tár és az alkalmazásadatok különálló adatbázisokra való leválasztása csak akkor hasznos, ha több olyan alkalmazással rendelkezik, amelyek mindegyike külön adatbázisokat használ, de közös felhasználói tárolót kell megosztania.

A második oktatóanyag óta készült alkalmazásnak még nincs szüksége adatbázisra. Most azonban szükségünk van egyre a felhasználói tárolóhoz. Hozzunk létre egyet, majd adjuk hozzá a SqlMembershipProvider szolgáltató által igényelt sémát (lásd: 2. lépés).

A Megoldáskezelőben kattintson a jobb gombbal a App_Data mappára, és válassza az Új elem hozzáadása lehetőséget. (Ha nem lát App_Data mappát a projektben, kattintson a jobb gombbal a projektre a Megoldáskezelőben, válassza a ASP.NET mappa hozzáadása lehetőséget, és válassza a App_Data.) Az Új elem hozzáadása párbeszédpanelen válasszon egy új, SecurityTutorials.mdfnevű SQL Database-adatbázist. Ebben az oktatóanyagban hozzáadjuk a SqlMembershipProvider sémát az adatbázishoz; a későbbi oktatóanyagokban további táblákat hozunk létre az alkalmazásadatok rögzítéséhez.

1. ábra: Új, SecurityTutorials.mdf nevű SQL Database hozzáadása a App_Data mappához (Kattintással megtekintheti a teljes méretű kép)

Ha hozzáad egy adatbázist a App_Data mappához, az automatikusan bele van foglalva az Adatbáziskezelő nézetbe. (A Visual Studio nem Express Edition verziójában az Adatbázis-kezelő neve Kiszolgálókezelő.) Nyissa meg az Adatbáziskezelőt, és bontsa ki az imént hozzáadott SecurityTutorials adatbázist. Ha nem látja az Adatbázis-kezelőt a képernyőn, nyissa meg a Nézet menüt, és válassza az Adatbázis-kezelőt, vagy nyomja le a Ctrl+Alt+S billentyűkombinációt. A 2. ábrán látható, hogy a SecurityTutorials adatbázis üres – nem tartalmaz táblákat, nézeteket és tárolt eljárásokat.

2. ábra: A SecurityTutorials adatbázis jelenleg üres (Kattintással megtekintheti a teljes méretű kép)

A SqlMembershipProvider a felhasználói tároló adatbázisában bizonyos táblákat, nézeteket és tárolt eljárásokat kell telepíteni. Ezek a szükséges adatbázis-objektumok a aspnet_regsql.exe eszközhasználatával vehetők fel. Ez a fájl a %WINDIR%\Microsoft.Net\Framework\v2.0.50727\ mappában található.

A aspnet_regsql.exe eszközzel ASP.NET alkalmazásszolgáltatásokat adhat hozzá vagy távolíthat el egy adott SQL Server-adatbázishoz. A ASP.NET alkalmazásszolgáltatások magukban foglalják a SqlMembershipProvider és a SqlRoleProvidersémáit, valamint a más ASP.NET 2.0-s keretrendszerekhez tartozó SQL-alapú szolgáltatók sémáit. Két bitnyi információt kell megadnunk a aspnet_regsql.exe eszköznek:

• Az alkalmazásszolgáltatások hozzáadását vagy eltávolítását, valamint
• Az az adatbázis, amelyből az Application Services-séma hozzáadható vagy eltávolítható

Amikor az adatbázis használatára kéri, a aspnet_regsql.exe eszköz arra kéri, hogy adja meg annak a kiszolgálónak a nevét, amelyen az adatbázis található, az adatbázishoz való csatlakozáshoz szükséges biztonsági hitelesítő adatokat és az adatbázis nevét. Ha az SQL Server nem Express kiadását használja, akkor ezt az információt már ismernie kell, mivel ugyanazt az információt kell megadnia egy kapcsolati sztringen keresztül, amikor egy ASP.NET weblapon keresztül dolgozik az adatbázissal. A kiszolgáló és az adatbázis nevének meghatározása az SQL Server 2005 Express Edition-adatbázis App_Data mappában való használatakor azonban egy kicsit nagyobb szerepet játszik.

Az alábbi szakasz az SQL Server 2005 Express Edition-adatbázisok kiszolgálójának és adatbázisának nevének App_Data mappában való megadásának egyszerű módját vizsgálja. Ha nem az SQL Server 2005 Express Editiont használja, nyugodtan ugorjon az Application Services telepítése szakaszra.

A aspnet_regsql.exe eszköz használatához ismerni kell a kiszolgáló és az adatbázis nevét. A kiszolgáló neve localhost\InstanceName. Valószínűleg a InstanceNameSQLExpress. Ha azonban manuálisan telepítette az SQL Server 2005 Express Editiont (vagyis nem telepítette automatikusan a Visual Studio telepítésekor), akkor lehetséges, hogy másik példánynevet választott.

Az adatbázis neve egy kicsit bonyolultabb meghatározni. A App_Data mappában lévő adatbázisok általában olyan adatbázisnévvel rendelkeznek, amely globálisan egyedi azonosítót az adatbázisfájl elérési útjával együtt. A aspnet_regsql.exesegítségével meg kell határoznunk az adatbázis nevét, hogy hozzáadhassuk az alkalmazásszolgáltatások sémáját.

Az adatbázis nevének megállapításához a legegyszerűbben az SQL Server Management Studión keresztül vizsgálhatja meg. Az SQL Server Management Studio grafikus felületet biztosít az SQL Server 2005-adatbázisok kezeléséhez, de nem az SQL Server 2005 Express Kiadásával szállítja. A jó hír az, hogy letöltheti az SQL Server Management Studio ingyenes Express Kiadását.

Először zárja be a Visual Studio-t, és győződjön meg arról, hogy a Visual Studio által az adatbázisfájlra vonatkozó zárolások bezárultak. Ezután indítsa el az SQL Server Management Studiót, és csatlakozzon az SQL Server 2005 Express Edition localhost\InstanceName adatbázisához. Korábban említettük, hogy a példány neve valószínűleg SQLExpress. A Hitelesítés beállításnál válassza a Windows-hitelesítés lehetőséget.

3. ábra: Csatlakozás az SQL Server 2005 Express Edition-példányhoz (Kattintással megtekintheti a teljes méretű kép)

Miután csatlakozott az SQL Server 2005 Express Edition-példányhoz, a Management Studio megjeleníti az adatbázisok mappáit, a biztonsági beállításokat, a kiszolgálóobjektumokat stb. Ha kibontja az Adatbázisok lapot, láthatja, hogy a SecurityTutorials.mdf adatbázis nincs regisztrálva az adatbázispéldányban – először csatolnunk kell az adatbázist.

Kattintson a jobb gombbal az Adatbázisok mappára, és válassza a Helyi menü Csatolás parancsát. Ekkor megjelenik az Adatbázisok csatolása párbeszédpanel. Innen kattintson a Hozzáadás gombra, keresse meg a SecurityTutorials.mdf adatbázist, és kattintson az OK gombra. A 4. ábrán az Adatbázisok csatolása párbeszédpanel látható, miután a SecurityTutorials.mdf adatbázis ki lett választva. Az 5. ábrán a Management Studio Objektumkezelője látható az adatbázis sikeres csatolása után.

4. ábra: Csatolja a SecurityTutorials.mdf-adatbázist (Kattintással megtekintheti a teljes méretű kép)

5. ábra: A SecurityTutorials.mdf adatbázis megjelenik az Adatbázisok mappában (Kattintással megtekintheti a teljes méretű kép)

Ahogy az 5. ábrán látható, a SecurityTutorials.mdf adatbázisnak meglehetősen abstruse neve van. Váltsuk át egy emlékezetesebb (és könnyebben beírható) névre. Kattintson a jobb gombbal az adatbázisra, válassza az Átnevezés lehetőséget a helyi menüből, és nevezze át SecurityTutorialsDatabase. Ez nem változtatja meg a fájlnevet, csak azt a nevet, amelyet az adatbázis az SQL Server felé való azonosításhoz használ.

6. ábra: Nevezze át az adatbázist SecurityTutorialsDatabase(Kattintással megtekintheti a teljes méretű kép)

Ezen a ponton ismerjük a SecurityTutorials.mdf adatbázisfájl kiszolgáló- és adatbázisnevét: localhost\InstanceName és SecurityTutorialsDatabase. Most már készen állunk az alkalmazásszolgáltatások telepítésére az aspnet_regsql.exe eszközzel.

A aspnet_regsql.exe eszköz elindításához nyissa meg a start menüt, és válassza a Futtatás lehetőséget. Írja be %WINDIR%\Microsoft.Net\Framework\v2.0.50727\aspnet_regsql.exe a szövegmezőbe, és kattintson az OK gombra. Másik lehetőségként a Windows Intézőt használva navigálhat a megfelelő mappához, és duplán kattinthat a aspnet_regsql.exe fájlra. Mindkét megközelítés ugyanazt az eredményt fogja eredményezni.

A aspnet_regsql.exe eszköz parancssori argumentumok nélküli futtatása elindítja a ASP.NET SQL Server telepítővarázsló grafikus felhasználói felületét. A varázsló megkönnyíti a ASP.NET alkalmazásszolgáltatások hozzáadását vagy eltávolítását egy megadott adatbázison. A varázsló első képernyője, amely a 7. ábrán látható, az eszköz célját ismerteti.

7. ábra: A ASP.NET SQL Server telepítővarázslójának használatával adja hozzá a tagsági sémát (Kattintással megtekintheti a teljes méretű kép)

A varázsló második lépése megkérdezi, hogy fel szeretnénk-e venni vagy eltávolítani az alkalmazásszolgáltatásokat. Mivel hozzá szeretnénk adni a SqlMembershipProviderszükséges táblákat, nézeteket és tárolt eljárásokat, válassza az SQL Server konfigurálása alkalmazásszolgáltatásokhoz lehetőséget. Később, ha el szeretné távolítani ezt a sémát az adatbázisból, futtassa újra ezt a varázslót, de ehelyett válassza az Application Services adatainak eltávolítása meglévő adatbázis-beállításból.

8. ábra: Válassza az SQL Server alkalmazási szolgáltatásokhoz való konfigurálását lehetőséget (Kattintson ide a teljes méretű kép megtekintéséhez)

A harmadik lépés az adatbázis adatainak megadását kéri: a kiszolgáló nevét, a hitelesítési adatokat és az adatbázis nevét. Ha követte ezt az oktatóanyagot, és hozzáadta a SecurityTutorials.mdf adatbázist App_Data-hez, csatolta localhost\InstanceName-höz, és átnevezte SecurityTutorialsDatabase-ra, használja a következő értékeket:

• Kiszolgáló: localhost\InstanceName
• Windows-hitelesítés
• Adatbázis: SecurityTutorialsDatabase

9. ábra: Adja meg az adatbázis adatait (Kattintson ide a teljes méretű kép megtekintéséhez)

Az adatbázis adatainak megadása után kattintson a Tovább gombra. Az utolsó lépés összefoglalja a végrehajtandó lépéseket. Kattintson a Tovább gombra az alkalmazásszolgáltatások telepítéséhez, majd a Befejezés gombra a varázsló befejezéséhez.

A varázsló befejezése után térjen vissza a Visual Studióba, és keresse meg az Adatbázis-kezelőt. Nyissa ki a Táblák mappát. Olyan táblákat kell látnia, amelyek neve a aspnet_előtaggal kezdődik. Hasonlóképpen számos nézet és tárolt eljárás található a Nézetek és a Tárolt eljárások mappában. Ezek az adatbázis-objektumok alkotják az Application Services sémáját. A tagság- és szerepkörspecifikus adatbázis-objektumokat a 3. lépésben vizsgáljuk meg.

10. ábra: Számos táblázat, nézet és tárolt eljárás lett hozzáadva az adatbázishoz (Kattintással megtekintheti a teljes méretű kép)

Ezen a ponton létrehoztuk a SqlMembershipProvideráltal igényelt adatbázis-objektumokat. Azonban továbbra is arra kell utasítanunk a tagsági keretrendszert, hogy használja a SqlMembershipProvider (szemben például a ActiveDirectoryMembershipProvider), és hogy a SqlMembershipProvider használja a SecurityTutorials adatbázist. A 4. lépésben bemutatjuk, hogyan adhatja meg a használni kívánt szolgáltatót, és hogyan szabhatja testre a kiválasztott szolgáltató beállításait. Először is nézzük meg részletesebben az imént létrehozott adatbázis-objektumokat.

Ha egy ASP.NET-alkalmazás tagsági és szerepkör-keretrendszereivel dolgozik, a megvalósítás részleteit a szolgáltató foglalja össze. A jövőbeli oktatóanyagokban ezeket a keretrendszereket a .NET-keretrendszer Membership és Roles osztályán keresztül fogjuk csatlakoztatni. A magas szintű API-k használatakor nem kell törődnünk az alacsony szintű részletekkel, például a lekérdezések végrehajtásával vagy a SqlMembershipProvider és a SqlRoleProvideráltal módosított táblákkal.

Ennek megfelelően magabiztosan használhatjuk a tagsági és szerepkör-keretrendszereket anélkül, hogy megvizsgálnánk a 2. lépésben létrehozott adatbázissémát. A táblák alkalmazásadatok tárolására való létrehozásakor azonban előfordulhat, hogy felhasználókhoz vagy szerepkörökhöz kapcsolódó entitásokat kell létrehoznunk. Az alkalmazás adattáblái és a 2. lépésben létrehozott táblák közötti idegenkulcs-megkötések létrehozásakor segít a SqlMembershipProvider és SqlRoleProvider sémák megismerésében. Ezenkívül bizonyos ritka esetekben előfordulhat, hogy közvetlenül az adatbázis szintjén kell csatlakozni a felhasználóhoz és a szerepkör-tárolókhoz (a Membership vagy Roles osztályok helyett).

A tagsági és szerepkör-keretrendszerek úgy vannak kialakítva, hogy egyetlen felhasználó és szerepkörtár több különböző alkalmazás között is megosztható legyen. A tagsági vagy szerepkör-keretrendszereket használó ASP.NET alkalmazásoknak meg kell adniuk a használni kívánt alkalmazáspartíciót. Röviden, több webalkalmazás is használhatja ugyanazt a felhasználói és szerepkör-tárolót. A 11. ábra három alkalmazásba particionált felhasználói és szerepkör-tárolókat ábrázol: HRSite, CustomerSite és SalesSite. Ez a három webalkalmazás mindegyike saját egyedi felhasználóval és szerepkörrel rendelkezik, de mind fizikailag ugyanabban az adatbázistáblában tárolja a felhasználói fiókját és a szerepkör-adatait.

11. ábra: A felhasználói fiókok több alkalmazás között particionálódhatnak (Kattintással megtekintheti a teljes méretű kép)

A aspnet_Applications tábla határozza meg ezeket a partíciókat. Minden alkalmazás, amely az adatbázist használja a felhasználói fiókok adatainak tárolására, a táblázat egy sora jelöli. A aspnet_Applications táblázat négy oszlopból áll: ApplicationId, ApplicationName, LoweredApplicationNameés Description. ApplicationId uniqueidentifier típusú, és a tábla elsődleges kulcsa; ApplicationName minden alkalmazáshoz egyedi, emberbarát nevet ad.

A többi tagsággal és szerepkörnel kapcsolatos tábla a aspnet_ApplicationsApplicationId mezőjére hivatkozik. Az egyes felhasználói fiókok rekordját tartalmazó aspnet_Users tábla például egy ApplicationId idegenkulcs-mezővel rendelkezik; ditto a aspnet_Roles táblához. A táblák ApplicationId mezője határozza meg azt az alkalmazáspartíciót, amelyhez a felhasználói fiók vagy szerepkör tartozik.

A felhasználói fiókok adatai két táblában találhatók: aspnet_Users és aspnet_Membership. A aspnet_Users tábla olyan mezőket tartalmaz, amelyek a felhasználói fiók alapvető adatait tartalmazzák. A három legfontosabb oszlop a következő:

• UserId
• UserName
• ApplicationId

UserId az elsődleges kulcs (és típusa uniqueidentifier). UserName nvarchar(256) típusú, és a jelszóval együtt a felhasználó hitelesítő adatait is alkotják. (A felhasználó jelszava a aspnet_Membership táblában van tárolva.) ApplicationId a felhasználói fiókot egy adott alkalmazáshoz kapcsolja aspnet_Applications. Az UserName és ApplicationId oszlopokon van egy összetett UNIQUE kényszer. Ez biztosítja, hogy egy adott alkalmazásban minden UserName egyedi legyen, de lehetővé teszi, hogy ugyanazt a UserName használhassa a különböző alkalmazásokban.

A aspnet_Membership táblázat további felhasználói fiókadatokat tartalmaz, például a felhasználó jelszavát, e-mail-címét, az utolsó bejelentkezési dátumot és időpontot stb. A aspnet_Users és aspnet_Membership táblák rekordjai egy-az-egyhez egyezést tartalmaznak. Ezt a kapcsolatot a tábla elsődleges kulcsaként szolgáló aspnet_MembershipUserId mezője biztosítja. A aspnet_Users táblához hasonlóan aspnet_Membership tartalmaz egy ApplicationId mezőt, amely ezeket az információkat egy adott alkalmazáspartícióhoz iktatja.

A jelszóadatokat a rendszer a aspnet_Membership táblában tárolja. A SqlMembershipProvider lehetővé teszi a jelszavak adatbázisban való tárolását az alábbi három módszer egyikével:

• törlése – a jelszó egyszerű szövegként van tárolva az adatbázisban. Határozottan elriasztom ezt a lehetőséget. Ha az adatbázist feltörik – legyen az egy hacker, aki talál egy hátsó ajtót vagy egy elégedetlen alkalmazottat, aki adatbázis-hozzáféréssel rendelkezik – minden egyes felhasználó hitelesítő adatai rendelkezésre állnak a felvételhez.
• kivonatolt – a jelszavak kivonatolódása egy egyirányú kivonatoló algoritmussal és egy véletlenszerűen létrehozott sóértékkel történik. Ez a kivonatolt érték (a sóval együtt) az adatbázisban van tárolva.
• Titkosított – a jelszó titkosított verziója az adatbázisban lesz tárolva.

A használt jelszótárolási technika a Web.configSqlMembershipProvider beállításaitól függ. A 4. lépésben áttekintjük a SqlMembershipProvider beállításainak testreszabását. Az alapértelmezett viselkedés a jelszó kivonatának tárolása.

A jelszó tárolásáért felelős oszlopok a következők: Password, PasswordFormatés PasswordSalt. PasswordFormat olyan int típusú mező, amelynek értéke a jelszó tárolására használt technikát jelzi: 0 a Törlés; 1 a kivonatolt; 2 a Encryptedhez. PasswordSalt véletlenszerűen létrehozott sztring van hozzárendelve a használt jelszótárolási technikától függetlenül; a PasswordSalt értéke csak a jelszó kivonatának kiszámításakor használatos. Végül a Password oszlop tartalmazza a tényleges jelszóadatokat, legyen szó egyszerű szöveges jelszóról, a jelszó kivonatáról vagy a titkosított jelszóról.

Az 1. táblázat bemutatja, hogy ez a három oszlop milyen lehet a mySecret jelszó tárolásakor használt különböző tárolási technikákhoz. .

1. táblázat: Példaértékek a Password-Related mezőkhöz a Jelszó MySecret!

A Szerepkörök keretrendszer lehetővé teszi a fejlesztők számára, hogy szerepköröket definiáljanak, és megadják, hogy a felhasználók milyen szerepkörökhöz tartoznak. Ez az információ két táblán keresztül van rögzítve az adatbázisban: aspnet_Roles és aspnet_UsersInRoles. A aspnet_Roles tábla minden rekordja egy adott alkalmazás szerepkörét jelöli. A aspnet_Users táblához hasonlóan a aspnet_Roles táblázat három oszlopból áll:

• RoleId
• RoleName
• ApplicationId

RoleId az elsődleges kulcs (és típusa uniqueidentifier). A RoleName a(z) nvarchar(256)típusú. És ApplicationId összekapcsolja a felhasználói fiókot egy adott alkalmazással aspnet_Applications. A RoleName és ApplicationId oszlopokra összetett UNIQUE korlátozás érvényes, amely biztosítja, hogy az egyes szerepkörnevek egyediek legyenek egy adott alkalmazásban.

A aspnet_UsersInRoles tábla a felhasználók és a szerepkörök közötti leképezést szolgálja. Csak két oszlop van - UserId és RoleId -, és együttesen alkotnak egy összetett elsődleges kulcsot.

A szolgáltatói modellt támogató összes keretrendszer – például a tagsági és szerepkör-keretrendszerek – nem rendelkeznek megvalósítási részletekkel, és ehelyett ezt a felelősséget egy szolgáltatói osztálynak delegálják. A tagsági keretrendszer esetében a Membership osztály határozza meg a felhasználói fiókok kezelésére szolgáló API-t, de nem lép kapcsolatba közvetlenül egyetlen felhasználói tárral sem. Ehelyett a Membership osztály metódusai átadják a kérést a konfigurált szolgáltatónak – a SqlMembershipProviderfogjuk használni. Amikor meghívjuk az Membership osztály egyik metódusát, honnan tudja a tagsági keretrendszer, hogy delegálja a hívást a SqlMembershipProvider?

A Membership osztály rendelkezik egy Providers tulajdonsággal, amely a tagsági keretrendszer által használható összes regisztrált szolgáltatói osztályra mutató hivatkozást tartalmaz. Minden regisztrált szolgáltatóhoz tartozik egy név és típus. A név emberbarát módon hivatkozhat egy adott szolgáltatóra a Providers gyűjteményben, míg a típus a szolgáltatóosztályt azonosítja. Emellett minden regisztrált szolgáltató konfigurációs beállításokat is tartalmazhat. A tagsági keretrendszer konfigurációs beállításai közé tartozik többek között a passwordFormat és a requiresUniqueEmail, még számos más mellett. A SqlMembershipProvideráltal használt konfigurációs beállítások teljes listáját a 2. táblázatban találja.

A Providers tulajdonság tartalma a webalkalmazás konfigurációs beállításain keresztül van megadva. Alapértelmezés szerint minden webalkalmazás rendelkezik egy AspNetSqlMembershipProvider nevű SqlMembershipProvidertípusú szolgáltatóval. Ez az alapértelmezett tagsági szolgáltató regisztrálva van a machine.config (található a %WINDIR%\Microsoft.Net\Framework\v2.0.50727\CONFIG):

Ahogy a fenti korrektúra is mutatja, a <membership> elem határozza meg a tagsági keretrendszer konfigurációs beállításait, míg a <providers> gyermekelem a regisztrált szolgáltatókat. A szolgáltatók a <add> vagy <remove> elemek használatával vehetők fel vagy távolíthatók el; az <clear> elem használatával távolítsa el az összes jelenleg regisztrált szolgáltatót. Ahogy a jelölés fent is mutatja, machine.config hozzáad egy AspNetSqlMembershipProvider nevű szolgáltatót, amely SqlMembershipProvidertípusú.

A name és type attribútumok mellett a <add> elem olyan attribútumokat is tartalmaz, amelyek meghatározzák a különböző konfigurálási beállítások értékeit. A 2. táblázat felsorolja az elérhető SqlMembershipProvider-specifikus konfigurációs beállításokat, valamint az egyes beállítások leírását.

2. táblázat: Tagság és SqlMembershipProvider konfigurációs beállítások

A AspNetSqlMembershipProvidermellett más tagsági szolgáltatók is regisztrálhatók alkalmazásonként, ha hasonló korrektúrát ad hozzá a Web.config fájlhoz.

Az alapértelmezett SqlMembershipProvider (AspNetSqlMembershipProvider) connectionStringName attribútuma LocalSqlServer. A AspNetSqlMembershipProvider szolgáltatóhoz hasonlóan a kapcsolati karakterlánc neve LocalSqlServer meg van határozva machine.config-ben.

Mint látható, ez a kapcsolati sztring egy SQL 2005 Express Edition-adatbázist határoz meg, amely a következő helyen található: |DataDirectory|aspnetdb.mdf'. A sztring |DataDirectory| futásidőben átalakul, hogy a ~/App_Data/ könyvtárra mutasson, így az adatbázis útvonala |DataDirectory|aspnetdb.mdf" a ~/App_Data/aspnet.mdf.

Ha nem adtunk meg tagságszolgáltatói adatokat az alkalmazás Web.config fájljában, az alkalmazás az alapértelmezett regisztrált tagságszolgáltatót használja, AspNetSqlMembershipProvider. Ha a ~/App_Data/aspnet.mdf adatbázis nem létezik, a ASP.NET futtatókörnyezet automatikusan létrehozza és hozzáadja az Application Services-sémát. Azonban nem szeretnénk a aspnet.mdf adatbázist használni; ehelyett a 2. lépésben létrehozott SecurityTutorials.mdf adatbázist szeretnénk használni. Ez a módosítás kétféleképpen valósítható meg:

• Adja meg aLocalSqlServerkapcsolati sztring nevének értékét aWeb.config. A LocalSqlServer kapcsolati sztringnév értékének felülírásával Web.confighasználhatjuk a regisztrált alapértelmezett Tagsági szolgáltatót (AspNetSqlMembershipProvider), és az megfelelően működni fog az SecurityTutorials.mdf adatbázissal. Ez a módszer akkor megfelelő, ha elégedett a AspNetSqlMembershipProvideráltal megadott konfigurációs beállításokkal. Erről a technikáról további információt Scott Guthrie blogbejegyzésében talál, ASP.NET 2.0 Application Services konfigurálása SQL Server 2000 vagy SQL Server 2005használatára.
• Adjon hozzá egy új regisztráltSqlMembershipProviderszolgáltatót, és konfigurálja aconnectionStringNamebeállítást, hogy az aSecurityTutorials.mdfadatbázisra mutasson. Ez a módszer olyan helyzetekben hasznos, amikor az adatbázis kapcsolati sztringje mellett más konfigurációs tulajdonságokat is testre szeretne szabni. Saját projektjeimben mindig ezt a megközelítést használom rugalmassága és olvashatósága miatt.

Mielőtt hozzáadhatnánk egy új regisztrált szolgáltatót, amely a SecurityTutorials.mdf adatbázisra hivatkozik, először hozzá kell adnunk egy megfelelő kapcsolati sztringértéket a Web.config<connectionStrings> szakaszában. Az alábbi korrektúra hozzáad egy SecurityTutorialsConnectionString nevű új kapcsolati sztringet, amely az SQL Server 2005 Express Edition SecurityTutorials.mdf adatbázisra hivatkozik a App_Data mappában.

Ezután adja hozzá az alábbi tagságkonfigurációs jelölőt a Web.config fájlhoz. Ez a jelölés regisztrál egy új szolgáltatót a SecurityTutorialsSqlMembershipProvidernévvel.

A SecurityTutorialsSqlMembershipProvider szolgáltató regisztrálása mellett a fenti korrektúra az SecurityTutorialsSqlMembershipProvider határozza meg alapértelmezett szolgáltatóként (a <membership> elem defaultProvider attribútumán keresztül). Ne feledje, hogy a tagsági keretrendszer több regisztrált szolgáltatóval is rendelkezhet. Mivel a AspNetSqlMembershipProvider az első szolgáltatóként van regisztrálva a machine.config, az alapértelmezett szolgáltatóként szolgál, hacsak másként nem jelezzük.

Az alkalmazás jelenleg két regisztrált szolgáltatóval rendelkezik: AspNetSqlMembershipProvider és SecurityTutorialsSqlMembershipProvider. A SecurityTutorialsSqlMembershipProvider szolgáltató regisztrálása előtt azonban törölhettük volna az összes korábban regisztrált szolgáltatót úgy, hogy közvetlenül a <add> elem elé adtunk hozzá egy <clear /> elemet. Ez törli a AspNetSqlMembershipProvider a regisztrált szolgáltatók listájából, ami azt jelenti, hogy az SecurityTutorialsSqlMembershipProvider lenne az egyetlen regisztrált tagságszolgáltató. Ha ezt a megközelítést használjuk, akkor nem kell alapértelmezett szolgáltatóként megjelölnünk a SecurityTutorialsSqlMembershipProvider, mivel ez lenne az egyetlen regisztrált tagsági szolgáltató. További információ a <clear />használatáról: A <clear /> használata szolgáltatók hozzáadásakor.

Vegye észre, hogy a SecurityTutorialsSqlMembershipProviderconnectionStringName beállítása az imént hozzáadott SecurityTutorialsConnectionString kapcsolati sztring nevére hivatkozik, és hogy a applicationName beállítása SecurityTutorials értékre lett állítva. Ezenkívül a requiresUniqueEmail beállítás true-re lett beállítva. Minden más konfigurációs beállítás megegyezik a AspNetSqlMembershipProviderértékeinek. Ha szeretné, itt bármilyen konfigurációmódosítást elvégezhet. Például megszűkítheti a jelszó erősségét úgy, hogy két nem alfanumerikus karaktert követel meg egy helyett, vagy ha hét helyett nyolc karakterre növeli a jelszó hosszát.

Jelenleg van egy adatbázisunk a konfigurált alkalmazásszolgáltatásokkal (SecurityTutorials.mdf), és úgy konfiguráltuk a webalkalmazást, hogy a tagsági keretrendszer az imént regisztrált SecurityTutorialsSqlMembershipProvider szolgáltatót használja. Ez a regisztrált szolgáltató SqlMembershipProvider típusú, és connectionStringName értéke a megfelelő kapcsolati karakterláncra (SecurityTutorialsConnectionString) van állítva, míg applicationName értéke kifejezetten meg van határozva.

Most már készen állunk az alkalmazás tagsági keretrendszerének használatára. A következő oktatóanyagban megvizsgáljuk, hogyan hozhat létre új felhasználói fiókokat. Ezt követően áttekintjük a felhasználók hitelesítését, a felhasználóalapú engedélyezést és a további, felhasználóval kapcsolatos információk tárolását az adatbázisban.

Boldog programozást!

Az oktatóanyagban tárgyalt témakörökről az alábbi forrásokban talál további információt:

• Mindig állítsa be a applicationName tulajdonságot a ASP.NET 2.0-s tagság és egyéb szolgáltatók konfigurálásakor
• ASP.NET 2.0 Application Services konfigurálása az SQL Server 2000 vagy az SQL Server 2005 használatára
• AZ SQL Server Management Studio letöltése
• ASP.NET 2.0 tagságának, szerepköreinek és profiljának vizsgálata
• A <add> elem a szolgáltatók számára a tagsághoz
• A <membership> elem
• Tagság <providers> eleme
• <clear /> használata szolgáltatók hozzáadásakor
• közvetlenül a SqlMembershipProvider

• Az ASP.NET tagsági rendszerek megértése

Scott Mitchell, több ASP/ASP.NET-könyv szerzője és a 4GuysFromRolla.com alapítója, 1998 óta dolgozik a Microsoft webtechnológiáival. Scott független tanácsadóként, edzőként és íróként dolgozik. Legújabb könyve Sams Teach Yourself ASP.NET 2.0 24 óra alatt. Scott elérhető a mitchell@4guysfromrolla.com vagy a blogján keresztül a http://ScottOnWriting.NET.

Ezt az oktatóanyag-sorozatot sok hasznos véleményező áttekintette. Az oktatóanyag vezető véleményezője Alicja Maziarz volt. Szeretné áttekinteni a közelgő MSDN-cikkeimet? Ha igen, dobj egy sort a mitchell@4GuysFromRolla.com.