Under normala omständigheter, när vi hanterar åtkomsträttigheter, sparar vi användarens grundläggande information efter korrekt inloggning i sessionen, och får den varje gång användaren begär sid- eller gränssnittsdata i framtiden
Session för att se och jämföra om han är inloggad och om han kan komma åt den aktuella sidan.
Principen för Session är att generera ett SessionID på serversidan som motsvarar den lagrade användardatan, och SessionID:t lagras i en cookie, och klienten bär med sig detta varje gång det begärs
Cookie, servern hittar data som lagras på serversidan baserat på sessions-ID:t i cookien.
FormsAuthentication tillhandahålls av Microsoft för oss utvecklare att använda för autentisering. Genom denna autentisering kan vi lagra användarnamnet och viss användardata i cookies,
Grundläggande identitets- och rollautentisering kan enkelt uppnås genom grundläggande villkorsinställningar.
Effekten som uppnås här är att implementera rollbaserad åtkomstkontroll med hjälp av det systemtillhandahållna Authorize utan medlemskap.
1. Skapa ett ärende
Efter att användaren loggat in lagras användarens ID och motsvarande roll (för flera roller, separata) i ärendet.
Kryptera ärendet med FormsAuthentication.Encrypt.
Spara det krypterade ärendet i Response-cookien (klientens js behöver inte läsa denna cookie, så det är bäst att ställa in HttpOnly=True för att förhindra webbläsarattacker från att stjäla och förfalska cookies). På så sätt kan du läsa det från Begäran-cookien nästa gång.
En enkel demo är följande:
bool isPersistent, //if to persist (sätt vid behov, om det är satt till persistens måste Expires-inställningen för cookien ställas in när en cookie skickas)
Den sjätte parametern i FormsAuthenticationTicket lagrar användarens Data av typsträngen, där roll-ID:t för den aktuella användaren lagras, separerat av en komma.
När man loggar in med användarnamnet "test" visas en loggkaka på klienten
2. Skaffa certifieringsinformation
Efter inloggning kan vi på innehållssidan få fram uname-informationen via User.Identity.Name av den aktuella förfrågan, eller så kan vi dekryptera cookien i begäran för att få ärendet, och sedan hämta uname och userData (det vill säga den tidigare lagrade roll-ID-informationen) därifrån.
3. Realisera behörighetsåtkomstkontroll genom annoteringsattribut
Konfigurera Aktivera formulärautentisering och rollhantering i web.config
När vi lägger till annoteringsegenskaper i Controller och Action, var får vi då den inställda rollen ifrån? Eftersom vi inte använder medlemskapsbaserad autentisering kommer vi också att skapa en anpassad RoleProvider. Namnet är CustomRoleProvider, som ärvs från RoleProvider. Här är skapandet av din egen CustomRoleProvider.cs-fil i Hjälper-mappen under MVCApp.
Det finns många abstrakta metoder i RoleProvider, och vi implementerar endast GetRolesForUser-metoden för att få användarroller. Användarrollen här kan efterfrågas från databasen baserat på det användar-ID som erhållits, eller det som lagras i sessionen eller i cookien. Här har jag redan lagrat rollen i userData för ärendet, så låt oss hämta den från ärendet.
Om det behövs, lägg till annoteringsattribut till den validerade Controllern eller Handlingen, till exempel tillåter denna åtgärd endast åtkomst med ett RoleID på 1, 2 eller 3, och den nuvarande användarens RoleID är (7, 1, 8), vilket innebär att användaren har rätt till åtkomst.
P.S. :1. Ticket lagras vid cookiens utgångstid, och om webbläsaren är stängd för att minnas den aktuella biljetten kan parametrarna ställas in när FormsAuthenticationTicket instansieras.
2. Förvärvet av Role kan läsas direkt från databasen utan att lagras i userData i ärendet, och userData kan lagra annan information.
3. Om du vill flexibelt konfigurera Controllerns och Actions tillåtna åtkomstroller kan du anpassa metoden OnAuthorization i AuthorizeAttribut-överskrivningen, där metoden används
Läs roll-ID:t som är tillåtet på den aktuella sidan och kontrollera det enligt den nuvarande användarens RoleID. På detta sätt realiseras den flexibla konfigurationen av rollen.
4. Informationen i ärendet lagras slutligen i cookien, och säkerheten är fortfarande upp till dig själv, jag tycker personligen att det är bättre att lagra UserID och RoleID i sessionen.
|
Publicerad på 2018-07-19 17:31:14
|
|
|
