V običajnih okoliščinah, ko upravljamo dostopne pravice, shranimo osnovne podatke uporabnika po pravilni prijavi v seji in jih dobimo vsakič, ko uporabnik v prihodnosti zahteva podatke o strani ali vmesniku
Seja za preverjanje in primerjavo, ali je prijavljen in ali lahko dostopa do trenutne strani.
Načelo Session je, da na strežniški strani ustvari SessionID, ki ustreza shranjenim uporabniškim podatkom, SessionID pa je shranjen v piškotku, odjemalec pa ga prenese s seboj vsakič, ko ga zahteva
Piškotek, strežnik najde podatke, shranjene na strežniški strani, glede na ID seje v piškotku.
FormsAuthentication zagotavlja Microsoft za nas razvijalce za uporabo za avtentikacijo. S to avtentikacijo lahko uporabniško ime in nekatere uporabniške podatke shranimo v piškotke,
Osnovno preverjanje identitete in vloge je mogoče enostavno doseči z osnovnimi nastavitvami pogojev.
Učinek, ki ga želimo doseči, je implementacija nadzora dostopa na osnovi vlog z uporabo sistemsko zagotovljenega Authorize brez uporabe članstva.
1. Ustvarite vstopnico
Ko se uporabnik prijavi, se uporabniški ID in ustrezna vloga (za več vlog, ločeno) shranita v vstopnico.
Vstopnico šifriraj s FormsAuthentication.Encrypt.
Shranite šifrirano vstopnico v piškotek Odgovor (odjemalec js tega piškotka ne rabi brati, zato je najbolje nastaviti HttpOnly=True, da preprečite krajo in ponarejanje piškotkov v brskalniku). Tako ga lahko naslednjič preberete iz piškotka Request.
Preprost demo je naslednji:
bool isPersistent, //ali naj ostane (nastavljeno po potrebi, če je nastavljeno na persistence, mora biti nastavitev Expires piškotka nastavljena ob pošiljanju piškotka)
Šesti parameter FormsAuthenticationTicket shrani userData iz niza tipa, kjer je shranjen ID vloge trenutnega uporabnika, ločen z vejico.
Ko se prijavite z uporabniškim imenom "test", se na odjemalcu prikaže dnevnik piškotka
2. Pridobivanje informacij o certifikaciji
Po prijavi lahko na vsebinski strani pridobimo podatke o uname preko User.Identity.Name trenutne zahteve ali pa dešifriramo piškotek v zahtevi za pridobitev vstopnice in nato pridobimo uname in userData (torej prej shranjene podatke o identifikaciji vloge).
3. Uresničitev nadzora dostopa do dovoljenj preko atributov označevanja
Nastavite omogočiti avtentikacijo obrazcev in upravljanje vlog v web.config
Ko dodamo lastnosti označevanja v Controller in Action, kje dobimo nastavljeno vlogo? Ker ne uporabljamo avtentikacije na osnovi članstva, bomo ustvarili tudi prilagojenega RoleProviderja. Ime je CustomRoleProvider, ki je podedovano od RoleProvider. Tukaj je ustvarjanje vaše lastne CustomRoleProvider.cs datoteke v mapi Helper pod MVCApp.
V RoleProviderju je veliko abstraktnih metod, pri čemer uporabljamo samo metodo GetRolesForUser za pridobivanje uporabniških vlog. Uporabniško vlogo je mogoče poizvedovati iz baze podatkov glede na pridobljeni uporabniški ID ali tistega, shranjenega v seji ali piškotku. Tukaj sem vlogo že shranil v uporabniške podatke zahtevka, zato jo pridobimo iz zahtevka.
Če je potrebno, dodajte atribute označevanja validiranemu krmilniku ali dejanju, na primer; to dejanje omogoča dostop le z RoleID 1, 2 ali 3, trenutni uporabniški RoleID pa je (7, 1, 8), kar pomeni, da ima uporabnik pravico do dostopa.
P.S. :1. Vstopnica se shrani ob času poteka piškotka, in če je brskalnik zaprt, da si zapomni trenutno vstopnico, se parametri lahko nastavijo ob vzpostavitvi FormsAuthenticationTicket.
2. Pridobivanje vloge je mogoče prebrati neposredno iz baze podatkov, ne da bi bilo shranjeno v uporabniških podatkih vstopnice, uporabniški podatki pa lahko shranijo druge informacije.
3. Če želite prilagodljivo konfigurirati dovoljeni dostopni vlogi krmilnika in akcije, lahko v preglasitvi AuthorizeAttribute prilagodite metodo OnAuthorization, kjer se metoda uporablja
Preberite ID vloge, ki je dovoljen na trenutni strani, in ga preverite glede na trenutni uporabniški RoleID. Na ta način se uresniči prilagodljiva konfiguracija vloge.
4. Podatki v zahtevku so na koncu shranjeni v piškotku, varnost pa je še vedno na vaši lastni presoji, osebno menim, da je bolje shraniti uporabniški ID in RoleID v seji.
|
Objavljeno na 19. 07. 2018 17:31:14
|
|
|
