Ich speichere Benutzerdaten in einer MSSQL-Tabelle namens Benutzer. Was ich möchte, ist Zugriff auf alle Benutzerdaten für tatsächlich angemeldete Benutzer (E-Mail, Adresse, Telefon, wenn der Benutzer Abonnent usw. ist).
Ich möchte keine Profile verwenden, daher habe ich mich dazu entschieden, einen benutzerdefinierten Mitgliedschaftsanbieter zu verwenden (oder kennen Sie einen besseren, weniger schmerzhaften Weg?).
Was ich nicht verstehe, ist MembershipUser und Membership. Wenn ich von MembershipProvider vererbte, kontrolliere ich in überschriebenen Methoden Zugriffsdaten von und zu Datenbank.
Aber wie verwende ich die geerbte Klasse von MembershipProvider? Wenn ich den Benutzer mithilfe der Mitgliedschaft authentifizieren möchte, muss ich Folgendes tun:
%Vor%Aber wo wird die Klasse von MembershipProvider geerbt? Und wann sollte man eine Klasse verwenden, die von MembershipUser geerbt wurde? Und was ist eine Beziehung zwischen Membership und MembershipProvider?
Obwohl es auf MSDN nicht kristallklar ist, ist es nicht so kompliziert. Es gibt drei Klassen:
Ein benutzerdefinierter MembershipProvider wird basierend auf der Konfiguration Ihrer Anwendung (nach Code in der Mitgliedschaft) ausgewählt: configuration / system.web / membership. Hier bringen Sie Ihren Provider ins Spiel. Ihre MembershipProvider-Implementierung muss so geschrieben sein, dass sie auf den von Ihnen bevorzugten Datenspeicher für Benutzer zugreift: in diesem Fall Ihre Benutzertabelle.
MembershipUser-Objekte werden nur über Ihren MembershipProvider erstellt. Die MembershipProvider.ValidateUser () -Methode sollte für Ihren Datenspeicher überprüfen, ob die Kombination aus Benutzer und Kennwort gültig ist. Der MembershipProvider.GetUser () ruft Benutzerinformationen ab - verwenden Sie sie innerhalb einer geschützten Seite, und übergeben Sie System.Web.HttpContext.Current.User.Identity.Name als aktuellen authentifizierten Benutzer.
Das sagte, ich hoffe, Sie sind sicher, dass Sie nicht benutze Profile und möchte wirklich eine separate Benutzertabelle haben. Wenn Sie eine interne Anwendung schreiben, verwenden Sie ein vorhandenes Active Directory oder LDAP -fähiger Datenspeicher würde die Verwaltungskosten und wahrscheinlich Sicherheitsrisiken reduzieren. Es gibt Hunderte von Dingen, die Sie beim Ausführen der MembershipProvider-Route leicht falsch machen können. Verwenden Sie gesalzene Hashes ? Wie schützen Sie die Benutzertabelle vor Manipulation? MSDN behandelt nur einen Bruchteil der Sicherheitsprobleme , mit denen Sie konfrontiert werden können.
Der verwendete Provider wird über die Datei web.config gesteuert. Sie können tatsächlich mehr als einen Anbieter festlegen und einen Standardanbieter haben. Überprüfen Sie: Ссылка .
Wenn die Mitgliedschaft so aufgerufen wird, wird nur der Standardanbieter verwendet. Sie würden MembershipUser erben, wenn Sie zusätzliche Informationen für den Benutzer bereitstellen möchten, dies jedoch den Rest Ihres Codes mit Ihrem spezifischen Anbieter verknüpft.
Tags und Links membership-provider membership