Rad bi naredil 100% varen login, pa nimam pojma, kako to doseči. V časih ko smo se ukvarjali s PHP-jem smo v Session zapisovali da je uporabnik prijavlen ali pa da ni.
Zanima me, kako se to dela v ASP.NET-u?
Pa še eno vprašanje. Kako bi v System.Web.Services.WebService dobil SessionID, ker Context.Session == null? Ne vem zakaj ne morem dostopati do session objekta, vendar je Session objekt null.
Avtor: fora, objavljeno na portalu SloDug.si (Arhiv)
bojanv - sreda, 11. april 2007
Ravno zaradi tega sem to začel delat. Tam je ena izmed točtk pri Prevention, ki sem jo pač implementiral. Sicer mala verjetnost, ampak verjetnost je, ki si jo pa jz nočem privoščit....ne kriptiram pa vseh podatkov, samo tiste, ki so mi sporni....
pril - sreda, 11. april 2007
Ja, se strinjam, 100% varne prijave ni... drugača je s cookiji kar v redu zaščita (session cookiji, seveda), če hočaš povečati varnost daš potem isto zadevo na https. To je najbolj enostavna rešitev. Lahko uporabiš tudi druge načine prijav (kot npr digest, ampak to je na drugem nivoju, ssl zagotavlja varen prenos, digest pa avtentikacijo, ti pa bi želel varno celotno sejo?). Moj enostaven zaključek bi bil: še so banke zadovoljne s certifikati, bo to čisto uporabna zadeva :-)Še o session objektu: same vsebine sesion objekta nima smisla kriptirati, ker ne gre s strežnika (s strežnika gre samo ključ po katerm spozna strežnik session v naslednjem zahtevku) Za session paziš da so elementi "Serializable" da lahko vse uporabiš na state strežniu (bazo samo če želiš da se seje restavrirajo, če zadeva pade, ampak običajno to nima smisla) - najbolje da že začneš razvijati aplikacijo tako da si odpreš state strežnik lokalno, in imaš potem sejo na njem. Morebitne težave z objekti ki se ne serializirajo sproti rešuješ kar med razvojem. No, to je potrebno samo za aplikacije, za katere veš, da bo veeeeeliiikooo zahtevkov, da boš moral zadeve teči na več strežnikih... lp, pl
bojanv - sreda, 11. april 2007
100% varna prijava ne obstaja, če mene vprašaš. Ampak temu se lahko približaš. Načinov je malo morje. Odvisno je od arhitekture, ki si jo izbereš. Lahko hraniš podatke v Session-u, lahko jih kriptiraš, lahko vsak prenos preneseš preko urlja, ki je spet kriptiran, lahko Session-e hraniš v bazi (da se še lahko poigravaš z web farmami). Jz osebno uporabljam enkripcijo za podatke v session (mogoče je počasneje, samo jz boljše spim), s tem, da mam vključeno še EnableViewStateMAC na true. Sem poskusil uporabit način od Microsoft-a, samo ima preveč funkcionalnosti pa sem rajši nardil svojo oskubljeno varianto. To še malo pocukraš s custom profile providerji pa bo. Drugo vprašanje: Zakaj bi pa rad mel tukaj session? Ni dostopen, ker po definiciji vsebuje vse elemente in način prenosa, ampak zaradi varnosti moraš povedat metodi, da mora bit Session noter. Torej, naredi sledeče.Tam, kjer mas WebMethod atribut, mu daj v parametre tole [WebMethod(EnableSession=true)] in naj bi zadeva špilala.....Več o tem si pa preberi tukaj.