Az elõzõ bejegyzésben megpróbáltam összeszedni mit is biztosít az IIS 7 az ASP.NET felhasználókezeléséhez beépítve, atív módon. Most megpróbálom végigvenni, hogy a fejlesztések során milyen eszközök állnak rendelkezésünkre a tényleges szolgáltatások kialakításához.

Fejlesztõi környezet

Amikor az ember dolgozni kezd az egyik legfontosabb dolog, hogy legyen egy jó szolgáltatásokat biztosító és kezesbárányként viselkedõ fejlesztõi környezetünk. Számomra ez a Visual Studio, melybõl jelenleg a Visual Studio Team System 2008 Development Edition-t használom. Természetesen a kliens egy Team Foundation Server-hez is kapcsolódik, és a fejlesztéseinket ezen keresztül kezeljük.

A jobb és hatékonyabb fejlesztés érdekében egy-két apróságot feltelepítettem a gépemre a fejlesztõi környezeten kívül. Az apróságok a következõk:

  • Microsoft .NET Framework 3.5
  • Microsoft ASP.NET Futures (July 2007)
  • Microsoft Device Emulator version 3.0 – ENU (ennek használatához – a hálózati kapcsolat miatt – kell még a Virtual PC 2007)
  • Microsoft Visual Studio 2008 Team Explorer – ENU
  • MSDN Library (aktuális verziók)

A fentiek mellett természetesen folyamatosan figyelem az Internet megjelenõ cikkeket, fejlesztési tippeket és mintakódokat.

ASP.NET komponensek

A feladatok ellátására a következõ komponensek állnak rendelkezésre:

  • LoginView
  • Login
  • PasswordRecovery
  • LoginStatus
  • LoginName
  • CreateUserWizard
  • ChangePassword

A nevek alapvetõen megadják a funkciótat, de van egy-két komponens ami nem egyértelmû elsõre. A legfontosabb számunkra a LoginView kontrol, amely segítségével ugyanazon az oldalon elhelyezhetünk a bejelentkezés állapotától függõen más és más jeleníthetõ meg ugyanazon a lapon.

Alapértlemezésben a komponensek angol feliratokat tartalmaznak, de minden felirat külön külön megadható (nem mondom kicsit idõigényes, de az ember egyszer elvégzi aztán copy-paste módon már szállítható is egyik projektbõl a másikba). A funkciók a szükséges helyeken lépésrõl lépésre változnak – mini wizard logika -, hogy mindig csak a szükséges adatmennyiség és információ legyen látható.

A kinézetet a gyár kinézetekbõl is választhatjuk, vagy saját stíluslapot is használhatunk. A gyári kinézet esetén a rendszer minden érintett komponens formázási adatait direktben állítja be, stíluslapot nem használ. Amennyiben stíluslapot használunk a kezeléshez, akkor arra figyelni kell, hogy minden kontrolrészhez csak egy-egy stílus adható meg, CSS stílusok halmozásából nem tudunk építkezni. 🙁

Hogyan használjuk?

Bejelentkezõ panel

A projekt során elsõ lépésben meghatároztuk milyen feladatokat kell a felhasználókezelés során alkalmazni. Ezt követõen módosítottuk a site érintett master page oldalait, és felkerült rá a felhasználói bejelentkezések és visszajelzések támogatását végzõ panel.

Loginra várva

Login után

Bejelentkezésre várva
(Anonymous View)

Bejelentkezés után
(LoggedIn View)

Jó kérdés lehet, miképp tud ugyanazon az oldalon más és más megjelenni a bejelentkezés állapotának függvényében? A válasz egyszerû, mert a LoginView objektum segítségével lehetõségünk van az Anonymous View és a LoggedIn View között. A fenti ábrán látható, hogy az egyik és másik állapotba miképp állítottuk össze a lehetõségeket.
Az Anonymous View-ban elsõnek – és az egész objekutmot uralva – a Login objektum került elhelyezésre. Ezen obejktum – a megadott adatok alapján – automatikusan rendezi a bejelentkeztetéshez szükséges valamennyi feladatot. Ha kell hibajelzést ad ha kell, és amennyiben a bejelentkezés rendben van a folyamat végén még a bejelentkezés dátumát is feljegyzi az adatbázisba – mindezeket automatikusan. E kontrol alatt került elhelyezésre további két fontos link, ugrás az elfelejtette jelszavát és az új regisztráció oldalakra. Ez a kettõ oldal természetesen külön külön lapokon került megvalósításra az érintett kontrolok bevonásával. 🙂
A LoggedIn View-ba elsõ lépésben nem túl sok került, hisz jelenleg nincs is sok tennivaló itt. Elsõ lépésben köszöntjük a bejelentkezett felhasználót (e sorban a LoginName kontrol segítségével megjelenítjük a felhasználó azonosítóját is). Elhelyezésre került e szekcióban továbbá egy a jelszócseréhez szükséges oldalra mutató link, valamint az aktuális felhasználó kijelentkezését kezelõ LoginStatus kontrol. Ez utóbbi érdekessége, hogy bár itt csak a kijelentkezésre használjuk, de a kontrol a bejelentkezés státuszának megfelelõen változtatja a megjelenített szöveget és szabályozhatjuk az elvégzendõ tevékenységet.

Új regisztráció

Az új regisztráció során feladatunk az összes szükséges adat begyûjtése és eltárolása az adatbázisban. A rendszer érdekessége, hogy a jelszavakat – automatikusan – csak kódolt formában tárolja. A kódolás mikéntjét a webalkalmazás Machine Key szekciójában állíthatjuk be. Ezt azért még valamennyire kezelhetjük a web.config fájl system.web > membership > providers szekciójában is (lásd késõbb).

A regisztrációt egy önálló oldalon elhelyezve a CreateUserWizard obejktum végzi.

Create User Wizard

Az adatok bekérését követõen a rendszer ellenõrzi a szükséges feltételeket (minden adat megadásra került-e, nincs-e bármilyen tiltott mezõegyezés már meglévõ adatokkal) és ezt követõen felveszi a felhasználót. A létrehozást követõen a felhasználó bejelentkezett helyzetben “találja magát”.

Elfelejtett jelszó

Amennyiben a felhasználó elfelejtette a jelszavát – tekintettel a biztonsági elvárásokra – azt nem tudja az üzemeltetõ személyzettõl megkérdezni. Ebbõl adódóan szükség van a jelszó pótlását megvalósító kontrolra. Ezt a feladatot a PasswordRecovery kontrol látja el. Ez az objektum is önálló oldalon került elhelyezésre az egyszerûbb és átláthatóbb kezelés érdekében.

Elfelejtett jelszó 1Elfelejtett jelszó 2
Elfelejtett jelszó cseréjének lépései

Az objektum feladata összetett és csak több lépésben megvalósítható. Az ábrán látható, hogy elsõ lépésben a rendszer felhasználói azonosítót kérdezi és amennyiben ezt a rendszerben azonosította, akkor következõ lépésben felteszi a felhasználói regisztráció során megadott biztonsági kérdést. Amennyiben az erre adott válasz megfelelõ, akkor a beállított e-mail címre elküldi a véletlenszerûen generált új jelszót.

Az elküldött levelet igény esetén – ez véleményem szerint kötelezõ – testreszabhatjuk. E testreszabás során tetszõlegesen módosíthatjuk a címzetteket (CC és BCC szekciót is alkalmazhatunk!), megadhatjuk a kiküldendõ levél tipusát (simply/html), a levél címsorát és tartalmát is. Amennyiben a tartalmat akarjuk megadni azt legkönnyebben egy tetszõleges fájl kijelölésével tehetjük meg. A levélben érdemes a felhasználót tájékoztatni arról, hogy a megjegyezhetetlen krix-krax helyett miként állíthat be magánk egy könnyebben megjegyezhetõ jelszót!

Jelszócsere

Utoljára maradt egy fontos feladat, a jelszó cseréje. Az ASP.NET keret erre is kész kontrolt kínál, ami megint egy önálló oldalon került elhelyezésre.

Jelszó cseréje

A jelszó cseréjéhez a rendszer megkérdezi a régi jelszavunkat és rákérdez (ellenõrzéssel) a továbbiakban alkalmazni kívánt jelszavunkra. Amennyiben hibát vétünk, akkor ezt megjeleníti számunkra, amennyiben minden okés, úgy elvégzi a jelszó cseréjét. Érdekesség, hogy bár bejelentkezve maradunk, már az új jelszavunk él – amit ha kértük is abejelentkezéskor a bejelentkezési adatok rögzítését gépünkön – a következõ bejelentkezéskor ismét meg kell adni. Az automatikus bejelentkezéshez szükséges HASH eltárolása csak ekkor történik meg gépünkön.

Elsõ tapasztalások, speciális beállítások

A kontrolok logikai mûködése fix, azt csak minimálisan lehet a web.config fájlból befolyásolni, de lehet! 🙂 Ez a lehetõség elsõsorban a jelszó kezelést és cseréjének feltételeit szabályozza. Amennyiben nem elégedünk meg az alapértelmezésben kikényszerített beállításokkal (minimum 7 karakteres jelszó, amibõl legalább 1 nem alfanumerikus), netán a biztonsági kérdést nem akarjuk alkalmazni, akkor nincs más lehetõségünk kézzel bûvölnünk kell a web.config fájlt a system.web > membership > providers résznél.

<providers> <remove name=AspNetSqlMembershipProvider/> <add name=AspNetSqlMembershipProvidertype=System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3aconnectionStringName=LocalSqlServerenablePasswordRetrieval=falseenablePasswordReset=truerequiresQuestionAndAnswer=trueapplicationName=/requiresUniqueEmail=falseminRequiredPasswordLength=6minRequiredNonalphanumericCharacters=0passwordFormat=HashedmaxInvalidPasswordAttempts=5passwordAttemptWindow=10passwordStrengthRegularExpression=“” /> </providers>

Megint csak azt kell mondanom, hogy amennyiben a paramétereket elolvassuk, máris magyarázatok nélkül is érthetõvé válik, melyik kapcsoló mire szolgál. Nem túl nehéz, mindenesetre trükkös a dolog, mert nehéz a leírásokban a nyomára bukkanni, persze ha már megvan akkor semmi gond, gyorsan megoldjuk a problémát.

Fontos testreszabási igényünk még a felhasználói adatok kiegészítése további információkkal. Ennek megoldása sem egyértelmû – számomra elsõre -, így ennek konkrét körbejárást követõen egy további post témaköre lesz.

Nos remélem a két post segítségével már más is olyan könnyedén állítja össze a felhasználókezelést mint az nekem megy, ill ahogy a Microsoft-nál azt megálmodták. Lássuk be nem nehéz, mindössze egy teszt projekten kell végigpróbálni, és ezt követõen hajrá, elõre! Már rendelkezésünkre áll ehhez a megfelelõ üzemeltetési lehetõségeket is biztosító szerveroldali környezet is. Szerintem már semmi sem tarthat vissza minket attól, hogy a gyakorlatban is használjuk ezt a lehetõséget (is).

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

*