Forms autentikacija

Forms autentikacija je standardni ASP.NET mehanizam koji koristi autentikacijski Cookie za spremanje korisničkih podataka. Može se koristiti sa ASP.NET membership and roles providerom i gotovim kontrolama za logiranje, ali ovdje je opisan način manualnog kreiranja autentikacijskog cookia. Sav promet nije kriptiran (osim mogućnosti binarne serijalizacije .NET objekata), i postoji mogućnost krađe cookia i krivog predstavljanja.

Konfiguracija web.configa ASP.NETa za upotrebu Forms autentikacije je vrlo kompleksna ;) :

<authentication mode="Forms"/>

Konfiguraciju web servisa (WCF) nije potrebno mijenjati kao na prethodnom principu sa SSLom, pošto se sadržaj SOAP poruka ne mijenja. Za autentikaciju klijenta potrebno je napravi web servis koji izvršava provjeru korisničkih podataka i sprema autentikacijski cookie u Response objekt, primjer (bez validacije korisnika):

[ServiceContract(Namespace = "")]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class AuthService
{
	[OperationContract]
	public bool Login(string username,string pass)
	{
		// provjera korisnika u bazi ...
		var ticket = new FormsAuthenticationTicket(1, username,								DateTime.Now,DateTime.Now.AddDays(7),true,"id"+username);

		var encrypt = FormsAuthentication.Encrypt(ticket);
		var authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encrypt);
		HttpContext.Current.Response.Cookies.Add(authCookie);
		return true; // moguce je i vratiti poruku greske ili slicno
	}

	[OperationContract]
	public void Signout()
	{
		FormsAuthentication.SignOut();
	}
}

Primjer autentikacije klijenta: Više...

Svaka poslovna Silverlight aplikacija zahtjeva prijavu korisnika, i na web servisu provjeru korisničkih podataka da bi se utvrdile dozvole izvršavanja metoda. WCF i Silverlight nude out-of-box autentikaciju koja se uglavnom zasnima na ASP.NET Membership provideru (u najvećem broju primjera dostupnih na netu). On radi tako da pripremi SQL Server bazu sa svojim tablicama, te se brine oko svih aspekata upravljanja korisnicima (prijava novog, promjena lozinke, osobni podaci, role,...). Kako ja u svojim aplikacijama nikada ne koristim taj membership provider, nego imam svoju bazu, svoje objekte (i ORM za pristup bazi), uz to sam uvjek bio pre ljen napraviti vlasitit membership provider, ne mogu iskoristiti gotove kontrole za prijavu. WCF nudi nekoliko načina prijave korisnika, od kojih su dva opisana ovdje.

Zahtjevi su jednostavni: prijava preko Silverlight aplikacije, metode web servisa ne smiju zahtjevati user id ili slično (npr. GetProducts(int logedUserID), provjera korisničkih podataka mora se obavljati u mojoj klasi, sa mojom bazom, svaki request/respons na Silverlight mora biti „potpisan“ sa ID-em logiranog korisnika, bilo preko cookia ili drugačije.

U ovom tekstu je opisana implementacija autentikacije Silverlight (SL) aplikacije na web servise. Opisana su dva načina konfiguracije WCF servisa, gdje se korisnički podaci spremaju u SOAP poruci i Http Coookiu. Svaki od thi načina ima neke prednosti i mane, a neki od njih su:

Napredni načini bindanja i behaviora WCF servisa (queues, reliable sessions, transactions, message-level security, peer-to-peer messaging, drugi protokoli osim HTTP, HTTPS, TCP) u Silverlightu nisu dostupni zbog ograničenja sandbox modela rada unutar browsera, tako da se može koristiti samo basicHttpBinding (ili neke custom verzije, uz dodatno konfiguriranje). Više...

Upravo sam potrošio 4 sata na traženje buga u jednoj Silverlight aplikaciji koju trenutno radim. Pošto sam na kraju ipak uspio pronaći u kojem zecu leži grm, i kako sam siguran da će netko osim mene doći do istog problema jer se radi o često korištenom obrascu ravzijanja, bilo bi dobro podjeliti ovaj mali tips&tricks koji može spasiti par sati uzaludnog traženja internetom (koje mene nije dovelo do rješenja ipak).

Bug izgleda ovako:

ovo je jedna kontrola u razvoju, i njezin zadatak je da ispisuje njezin status, dali je minimizirana i maksimizirana. To ispisuje ListBoxu, koji radi na sljedeći načim:

- na UserControl je postavljena DataContext klasa (MVVM pattern)
- ta ViewModel klasa ima jednu listu stringova definiranu kao ObservableCollection<string> property
- pomoći Binding sposobnosti, ažurirane vrijednosti u tom propertyu se automatski osvježavaju u ListBoxu, odnosno ispisuje lista tih stringova.
Primjer XAML deklaracije ListBoxa:

Bug je desi kada dodate više od 3-4 stringova u listu, i pokušate selektirati jednog, u ListBoxu će ostati selektirani, ili nasumično se selektirati više stavaka, kao što je prikazano u screenshotu (ListBox nema omogućeno selektiranje više od jedne stavke).. Više...

I konačno, prvi windaysi na kojima ći prisustvovati u cijelosti (ne ono: evo ti ulaznica na 2 sata, poslje mi vrati jer te zamjenjuje kolega), i to u velikome stilu; sa druge strane šanka! Odnosno speaker pulta ili kako se već to zove. Naime, pred par mjeseci sam prijavio nekoliko tema za prezentaciju, uglavnom vezanih za ASP.NET MVC i Silverlight, nakon čega je programski odbor konferencije slučajno izabrao jednu predloženu prezentaciju: Silverligh RIA Services!

Mali uvod u Silverlight RIA Services, počevši od uvoda u ADO.NET Astoriu, kasnije nazvanu ADO.NET Data Services, pa opet preimenovanu u WCF Data Services (marketing odjel si svašta dopušta izgleda). U osnovi, radi se o izlaganju REST sučelja, čime se omoguće pretraživanje podataka kreiranjem posebnog URLa, te operacija nad podacima upotrebom Http metoda Get, Post, Put i Delete.

Za razliku od "standardnog" web servis upita nad određenom metodom ili procedurom (RPC-nalik upiti), u RESTu nema izloženih metoda koje se mogu pozvati, nego se upiti provode nad (hijerarhiskim) modelom podataka. Kako to izgleda u praksi:

U izradi Silverlight (ili WPF, WinForms…) aplikacija, često se javlja potreba za komunikacijom različitih dijelova aplikacije, poput različitih User Control-a, instanciranih objekata i slično. Najbolje da jednim primjerom objasnim problematiku: za izradu Silverlight aplikacije za praćenje riječkog karnevala (izrađeno 2008., nadam se da je još online!) morao sam implementirati "pametno" sučelje, koje ispisuje informacije o trenutnoj skupini koja prolazi, označiti ju na listi, i još par sitnica. Te informacije sam dobivao preko web servisa u lokalni "provider" podataka, i pomoću evenata/delegata u kodu se predplaćivao na taj "providera" i slao potrebne objekte svim pretplatnicima na evente. Kako se sučelje sastoji od dosta user controla i custom controla, orkestracija pretplate prilikom starta aplikacije odnosno kreiranja objekata je bila relativno kompleksna. Na kraju izrade bilo mi je jasno da to i nije nabolje rješenje i da mora postojati jednostavniji način. Nedugo potom sam naišao na jedan design pattern, za koji sam znao da postoji ali ga nikada nisam imao priliku iskoristiti, pretpostavljam zbog samom načina rada web aplikacija. Radi se o Mediator patternu, koji definira komunikaciju između objekata.

Jedan od mojih prethodnih blog postova objašnjava izradu ViewModela, prema Model-View-ViewModel patternu. Mediator pattern se savršeno uklapa u naš ViewModel, stoga ćemo iskoristiti MVVM i dodati potrebne klase. 
U svojoj osnovi, stvar ovako funkcionira: objekti se pretplate (Subscribe(tip poruke)) na određene poruke Mediator objektu (MessageGateway u primjeru). Ti objekti mogu i poslati poruku (Publish(ChatMessage)) Mediator objektu, koji potom prosljeđuje poruku svim pretplatnicima koji su se pretplatili na taj tip poruke (ReceiveMessage(poruka)).Više...