Under normale omstendigheter, når vi administrerer tilgangsrettigheter, lagrer vi grunnleggende informasjon om brukeren etter korrekt innlogging i økten, og får den hver gang brukeren ber om side- eller grensesnittdata i fremtiden
Session for å se og sammenligne om han er logget inn og om han kan få tilgang til den nåværende siden.
Prinsippet for Session er å generere en SessionID på serversiden som tilsvarer de lagrede brukerdataene, og SessionID-en lagres i en informasjonskapsel, og klienten vil bære denne med seg hver gang den forespørres
Cookie, serveren finner dataene lagret på serversiden basert på sesjons-ID-en i cookien.
FormsAuthentication tilbys av Microsoft for oss utviklere til autentisering. Gjennom denne autentiseringen kan vi lagre brukernavnet og noe brukerdata i informasjonskapsler,
Grunnleggende identitets- og rolleautentisering kan enkelt oppnås gjennom grunnleggende tilstandsinnstillinger.
Effekten som oppnås her er å implementere rollebasert tilgangskontroll ved bruk av systemgitt Authorize uten å bruke medlemskap.
1. Opprette en sak
Etter at brukeren logger inn, lagres brukerens ID og tilsvarende rolle (for flere roller, adskilt) i saken.
Krypter billetten med FormsAuthentication.Encrypt.
Lagre den krypterte saken i Response-cookien (klientens js trenger ikke å lese denne cookien, så det er best å sette HttpOnly=True for å forhindre nettleserangrep fra å stjele og forfalske informasjonskapsler). På denne måten kan du lese den fra Request-cookien neste gang.
En enkel demo er som følger:
bool isPersistent, //if to persist (sett etter behov, hvis satt til persistens, må Expires-innstillingen for informasjonskapselen settes når en cookie sendes)
Den sjette parameteren i FormsAuthenticationTicket lagrer userData av typestrengen, hvor rolle-ID-en til den nåværende brukeren er lagret, adskilt med et komma.
Når man logger inn med brukernavnet "test", vises en logg-cookie på klienten
2. Innhente sertifiseringsinformasjon
Etter innlogging kan vi på innholdssiden hente uname-informasjonen via User.Identity.Name av den nåværende forespørselen, eller vi kan dekryptere informasjonskapselen i forespørselen for å hente saken, og deretter hente uname og userData (altså den tidligere lagrede rolle-ID-informasjonen) fra den.
3. Realisere tillatelsestilgang gjennom annotasjonsattributter
Konfigurer Aktiver skjemaautentisering og rollehåndtering i web.config
Når vi legger til annotasjonsegenskaper i Controller og Action, hvor får vi settet Role fra? Siden vi ikke bruker medlemskapsbasert autentisering, kommer vi også til å opprette en egendefinert RoleProvider. Navnet er CustomRoleProvider, som er arvet fra RoleProvider. Her er opprettelsen av din egen CustomRoleProvider.cs-fil i Hjelper-mappen under MVCApp.
Det finnes mange abstrakte metoder i RoleProvider, og vi implementerer kun GetRolesForUser-metoden for å hente brukerroller. Brukerrollen her kan forespørres fra databasen basert på bruker-ID-en som er oppnådd, eller den som er lagret i sesjonen eller i informasjonskapslen. Her har jeg allerede lagret rollen i userData for saken, så la oss hente den fra saken.
Om nødvendig, legg til annotasjonsattributter til den validerte kontrolleren eller handlingen, for eksempel tillater denne handlingen kun tilgang med en rolle-ID på 1 eller 2 eller 3, og den nåværende brukerens rolle-ID er (7, 1, 8), noe som betyr at brukeren har rett til tilgang.
P.S. :1. Ticket lagres ved cookie-utløpstidspunktet, og hvis nettleseren er lukket for å huske gjeldende ticket, kan parameterne settes når FormsAuthenticationTicket instansieres.
2. Anskaffelsen av Role kan leses direkte fra databasen uten å være lagret i userData i ticketen, og userData kan lagre annen informasjon.
3. Hvis du ønsker å fleksibelt konfigurere kontrollerens og handlingens tillatte tilgangsroller, kan du tilpasse OnAuthorization-metoden i AuthorizeAttribut-override, der metoden brukes
Les rolle-ID-en som er tillatt på den nåværende siden og sjekk den i henhold til den nåværende brukerens RoleID. På denne måten realiseres den fleksible konfigurasjonen av rollen.
4. Informasjonen i saken lagres til slutt i informasjonskapselen, og sikkerheten er fortsatt opp til deg selv, jeg mener personlig det er bedre å lagre UserID og RoleID i økten.
|
Publisert på 19.07.2018 17:31:14
|
|
|
