Unter normalen Umständen speichern wir bei der Zugriffsrechteverwaltung die Grundinformationen des Benutzers nach der korrekten Anmeldung in der Sitzung und erhalten sie jedes Mal, wenn der Nutzer in Zukunft Seiten- oder Schnittstellendaten anfordert
Sitzung, um zu sehen und zu vergleichen, ob er eingeloggt ist und ob er auf die aktuelle Seite zugreifen kann.
Das Prinzip von Session besteht darin, auf der Serverseite eine SessionID zu erzeugen, die den gespeicherten Benutzerdaten entspricht, und die SessionID wird in einem Cookie gespeichert, und der Client trägt diese jedes Mal mit, wenn sie angefordert wird
Cookie, der Server findet die auf der Serverseite gespeicherten Daten anhand der Session-ID im Cookie.
FormsAuthentication wird von Microsoft bereitgestellt, damit wir Entwickler sie zur Authentifizierung nutzen können. Durch diese Authentifizierung können wir den Benutzernamen und einige Benutzerdaten in Cookies speichern,
Grundlegende Identitäts- und Rollenauthentifizierung lassen sich leicht durch grundlegende Konditionseinstellungen erreichen.
Die Wirkung, die hier erreicht werden soll, ist die Implementierung rollenbasierter Zugriffskontrolle mit dem systembereitgestellten Authorize ohne Mitgliedschaft.
1. Ein Ticket erstellen
Nachdem der Benutzer sich eingeloggt hat, werden die Benutzer-ID und die entsprechende Rolle (für mehrere Rollen, getrennt) im Ticket gespeichert.
Verschlüsseln Sie das Ticket mit FormsAuthentication.Encrypt.
Speichere das verschlüsselte Ticket im Response-Cookie (der Client js muss dieses Cookie nicht lesen, daher ist es am besten, HttpOnly=True zu setzen, um Browserangriffe zu verhindern, die Cookies stehlen oder fälschen). So kannst du es beim nächsten Mal aus dem Anfrage-Cookie lesen.
Eine einfache Demo ist wie folgt:
bool isPersistent, //whether to persist (nach Bedarf eingestellt, wenn auf Persistenz gesetzt, muss die Expires-Einstellung des Cookies beim Senden eines Cookies gesetzt werden)
Der sechste Parameter von FormsAuthenticationTicket speichert den userData des Typs String, in dem die Rollen-ID des aktuellen Benutzers gespeichert ist, getrennt durch ein Komma.
Beim Einloggen mit dem Benutzernamen "Test" erscheint ein Log-Cookie auf dem Client
2. Zertifizierungsinformationen einholen
Nach dem Einloggen können wir auf der Inhaltsseite die uname-Informationen über die User.Identity.Name der aktuellen Anfrage erhalten, oder wir entschlüsseln das Cookie in der Anfrage, um das Ticket zu erhalten, und dann die uname und userData (also die zuvor gespeicherten Rollen-ID-Informationen) daraus abrufen.
3. Berechtigungszugriffskontrolle durch Annotationsattribute realisieren
Konfigurieren, Formularauthentifizierung und Rollenverwaltung in web.config aktivieren
Wenn wir Annotationseigenschaften zu Controller und Action hinzufügen, woher bekommen wir dann die Menge Rolle? Da wir keine mitgliedschaftsbasierte Authentifizierung verwenden, werden wir auch einen eigenen RoleProvider erstellen. Der Name ist CustomRoleProvider, der von RoleProvider übernommen wurde. Hier ist die Erstellung deiner eigenen CustomRoleProvider.cs-Datei im Helper-Ordner unter dem MVCApp.
Es gibt viele abstrakte Methoden in RoleProvider, und wir implementieren nur die GetRolesForUser-Methode, um Benutzerrollen zu erhalten. Die Benutzerrolle kann hier aus der Datenbank anhand der erhaltenen Benutzer-ID oder der in der Sitzung oder im Cookie gespeicherten ID abgefragt werden. Hier habe ich die Rolle bereits in den userData des Tickets gespeichert, also holen wir sie aus dem Ticket.
Falls nötig, fügen Sie Annotationsattribute zum validierten Controller oder der Aktion hinzu, zum Beispiel erlaubt diese Aktion nur Zugriff mit einer Rollen-ID von 1, 2 oder 3, und die aktuelle Benutzer-Rollen-ID ist (7, 1, 8), was bedeutet, dass der Benutzer das Recht auf Zugriff hat.
P.S. :1. Das Ticket wird zum Ablaufdatum des Cookies gespeichert, und wenn der Browser geschlossen ist, um das aktuelle Ticket zu merken, können die Parameter beim Instanziieren des FormsAuthenticationTicket eingestellt werden.
2. Die Übernahme von Role kann direkt aus der Datenbank gelesen werden, ohne in den userData des Tickets gespeichert zu sein, und userData kann weitere Informationen speichern.
3. Wenn Sie den Controller und die Erlaubten Zugriffsrollen von Action flexibel konfigurieren möchten, können Sie die OnAuthorization-Methode in der AuthorizeAttribut-Überschreibung, in der die Methode verwendet wird, anpassen
Lies die Rollen-ID, die auf der aktuellen Seite erlaubt ist, und überprüfe sie entsprechend der RoleID des aktuellen Nutzers. Auf diese Weise wird die flexible Konfiguration der Rolle realisiert.
4. Die Informationen im Ticket werden letztlich im Cookie gespeichert, und die Sicherheit liegt weiterhin in deinem eigenen Ermessen. Ich persönlich denke, es ist besser, die Benutzer-ID und die Rollen-ID in der Sitzung zu speichern.
|
Veröffentlicht am 19.07.2018 17:31:14
|
|
|
