CardSpace és ASP.NET AJAX 5: Adatok feldolgozása szerver oldalon

Aki a bevezetőtől kezdve egészen az előző részig lelkesen követte a CardSpace implementálásának lépéseit, mostanra eljutott odáig, hogy képes egy csili-vili felhasználói felületen keresztül egy gusztustalan XML-t elküldeni a kliensről szerver oldalra. A következő feladatunk, hogy mindezt feldolgozzuk.

Miután Server.HtmlDecode() segítségével visszaállítottuk azt az XML-t, amit az identity selector visszaadott, elkezdhetjük kibogarászni annak tartalmát. Ehhez nagyságrendileg 500 sor kódot kell írni, de ez mindegy is, hiszen erre szerintem halandók amúgy sem képesek. De ne keseredjünk el, keresgéljünk egy TokenProcessor nevű névteret lelkesen a guglival és ha elég ügyesek vagyunk, akkor meg is találjuk a CardSpace community site Samples galériájában Decrypting a Security Token (in C#) néven.

A használata pofonegyszerű: példányosítsuk meg a Token osztályt a klienstől kapott XML tokennel, majd a Claims tulajdonságon keresztül olvassuk ki a kártya egyes mezőinek értékét. Ez a tulajdonság sztringgel indexelhető, a sztringben pedig azokat a hosszú és megjegyezhetetlen séma URI-ket kell átadnunk, amiket már az OBJECT tag PARAM eleménél láttunk. Szerencsére ezek a konstansok elérhetőek a System.IdentityModel.Claims.ClaimTypes osztály tulajdonságaiként.

Az e-mail címet például így nyerhetjük ki a kártyából:

    string xmlToken = this.Server.HtmlDecode( this.hidIdentityToken.Value );
    Token token = new Token( xmlToken );
    string email = token.Claims[ ClaimTypes.Email ];

A kártyát egyedileg azonosító private personal identifiert a ClaimTypes.PPID segítségével olvashatjuk ki. Nem bonyolult ez, ha egyszer sikerül megfejteni!

Kártya adatainak tárolása és kezelése

Praktikus lenne eltárolnunk a kártya adatait egy adatbázis táblában. Az az út járható ugyanis, hogy a felhasználó beregisztrál a portálunkra, majd a személyes adatait kezelő oldalon hozzárendel egy kártyát a saját felhasználói fiókjához. Amikor legközelebb kártyával akar bejelentkezni, mi megnézzük, hogy az adott kártyához tartozik-e felhasználó és ha igen, bejelentkeztetjük.

Az én esetemben az adatbázis tábla így néz ki:

  • Id: uniqueidentifier DEFAULT( NewSequentialID() ) PK
  • UserId: uniqueidentifier
  • CardId: nvarchar( 255 )
  • DisplayName: nvarchar( 50 )

A CardId a kártya PPID-je, amiről nem találtam dokumentációt, hogy milyen hosszú lehet. Aki tudja, írja meg! A DisplayName pedig azért kell, hogy a felhasználónak meg tudjunk jeleníteni valami értelmeset a kártyáról. Össze lehet fűzni bele a givenname, surname és emailaddress claim-eket és akkor nem is kell küzdeni a kitöltésével.

Természetesen ezekhez kell írni tárolt eljárásokat, nálam ezek születtek, a nevek magukért beszélnek:

  • AddCard – kártya hozzárendelése a felhasználóhoz.
  • DeleteCard – kártya törlése.
  • GetCardsByUserId – a felhasználóhoz tartozó kártyák lekérdezése, hogy a személyes adatok oldalon meg tudjuk jeleníteni.
  • GetUserIdByCardId – bejelentkezéskor használjuk, hogy lekérdezzük az adott kártyához tartozó felhasználó azonosítóját.

Haladunk, de hátra van még, hogy ezeket a tárolt eljárásokat meghívjuk kódból. Erre sokféle megoldás létezik, mindenkinek biztosan van már kedvence, nagyon tudom javasolni a DLINQ használatát, ehhez Scott Guthrie-nál és Sahil Maliknál találunk útmutatást.

Végül ne felejtsünk el készíteni egy oldalt a bejelentkezett felhasználók számára, ahol hozzárendelhetnek kártyákat a felhasználói fiókjukhoz, megtekinthetik a korábban hozzárendelt kártyák adatait és törölhetik a hozzárendeléseket.

Utolsó lépésként pedig nem is marad más hátra, mint a felhasználó bejelentkeztetése InfoCard használatával…. Folyt. köv.

 

Technorati tags: , , ,

2 thoughts on “CardSpace és ASP.NET AJAX 5: Adatok feldolgozása szerver oldalon

  1. György

    Szia András!
     
    Teljesen igazad van! Eredetileg azt terveztem, hogy külön kitérek erre a kérdésre, de a linkeden található cikk magáért beszél, kár ragozni. Tudom még ajánlani annak a Garrett Seracknak a cikkét, aki a TokenProcessor osztályt írta: http://www.fearthecowboy.com/2007/01/me-and-my-ppid-can-i-rely-on-it.html
     
    A lényeg tömören: a felhasználó által felküldött claimek között található PPID önmagában jobb, mint a jelszó használata, de még nem a lehető legjobb. A TokenProcessor osztály tartalmaz egy UniqueID tulajdonságot, annak használatával fokozhatjuk a biztonságot.
     
    Köszi a visszajelzést!

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

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s