În condiții normale, când gestionăm drepturile de acces, salvăm informațiile de bază ale utilizatorului după autentificarea corectă în sesiune și le primim de fiecare dată când utilizatorul solicită date de pagină sau interfață în viitor
Sesiune pentru a vedea și a compara dacă este conectat și dacă poate accesa pagina curentă.
Principiul Session este de a genera un SessionID pe partea serverului corespunzător datelor utilizatorului stocate, iar SessionID-ul este stocat într-un cookie, iar clientul îl va purta cu el de fiecare dată când este solicitat
Cookie, serverul găsește datele stocate pe partea serverului pe baza ID-ului sesiunii din cookie.
FormsAuthentication este oferit de Microsoft pentru ca noi, dezvoltatorii, să o folosim pentru autentificare. Prin această autentificare, putem stoca numele de utilizator și unele date ale utilizatorului în cookie-uri,
Autentificarea de bază a identității și rolurilor poate fi realizată cu ușurință prin setări de condiții de bază.
Efectul de obținut aici este implementarea controlului accesului bazat pe roluri folosind Authorize furnizat de sistem, fără a folosi calitatea de membru.
1. Crearea unui tichet
După ce utilizatorul se conectează, ID-ul și rolul corespunzător (pentru mai multe roluri, separat) sunt stocate în tichet.
Criptează tichetul cu FormsAuthentication.Encrypt.
Stochează tichetul criptat în cookie-ul Răspuns (clientul js nu trebuie să citească acest cookie, așa că este mai bine să setezi HttpOnly=True pentru a preveni atacurile browserului care fură și falsifică cookie-uri). Astfel, poți citi data viitoare din cookie-ul Solicitare.
O demonstrație simplă este următoarea:
bool isPersistent, //dacă să persiste (setat după necesitate, dacă este setat pe persistență, setarea Expires a cookie-ului trebuie setată la trimiterea unui cookie)
Al șaselea parametru al FormsAuthenticationTicket stochează userData-ul șirului de tip, unde este stocat ID-ul rolului utilizatorului curent, separat printr-o virgulă.
Când te loghezi cu numele de utilizator "test", apare un cookie de log pe client
2. Obținerea informațiilor despre certificare
După autentificare, pe pagina de conținut, putem obține informațiile uname prin User.Identity.Name cererii curente sau putem decripta cookie-ul din cerere pentru a obține tichetul, apoi putem obține uname și userData (adică informațiile de ID de rol stocate anterior) de la acesta.
3. Realizarea controlului accesului prin permisiuni prin atribute de adnotare
Configurează, activează autentificarea formularelor și managementul rolurilor în web.config
Când adăugăm proprietăți de adnotare la Controller și Action, de unde obținem setul Role? Deoarece nu folosim autentificarea bazată pe membri, vom crea și un RoleProvider personalizat. Numele este CustomRoleProvider, moștenit de la RoleProvider. Iată crearea propriului tău fișier CustomRoleProvider.cs în folderul Helper sub MVCApp.
Există multe metode abstracte în RoleProvider, iar noi implementăm metoda GetRolesForUser doar pentru a obține rolurile utilizatorilor. Rolul utilizatorului aici poate fi interogat din baza de date conform ID-ului de utilizator obținut, fie cel stocat în sesiune sau stocat în cookie. Aici am stocat deja rolul în userData al tichetului, așa că să-l luăm din tichet.
Dacă este necesar, adăugați atribute de adnotare la Controlerul sau Acțiunea validată, de exemplu, această Acțiune permite accesul doar cu un RoleID de 1, 2 sau 3, iar RoleID-ul utilizatorului curent este (7, 1, 8), ceea ce înseamnă că utilizatorul are dreptul de acces.
P.S. :1. Tichetul este stocat la momentul expirării cookie-ului, iar dacă browserul este închis pentru a reține tichetul curent, parametrii pot fi setați când FormsAuthenticationTicket este instanțiat.
2. Achiziția Rolului poate fi citită direct din baza de date fără a fi stocată în userData al tichetului, iar userData poate stoca alte informații.
3. Dacă doriți să configurați flexibil Rolurile de Acces Permis ale Controlerului și Acțiunii, puteți personaliza metoda OnAuthorization în suprascrierea AuthorizeAttribute, în care este folosită metoda
Citește ID-ul rolului permis pe pagina curentă și verifică-l conform ID-ului de rol al utilizatorului curent. Astfel, se realizează configurația flexibilă a rolului.
4. Informațiile din tichet sunt stocate în cele din urmă în cookie, iar securitatea rămâne la discreția ta, personal cred că este mai bine să stochezi UserID-ul și RoleID-ul în sesiune.
|
Postat pe 19.07.2018 17:31:14
|
|
|
