ASP.NET MVC 2 - Membership-Provider - ValidateUser() - return-login-Fehlermeldung
Wie kann ich einen string zurückzugeben, der die Nachricht von der ValidateUser-Methode in meine custom membership provider? Ich brauche diese, weil ich möchte mehrere Prüfungen (Benutzer zugelassen ist, wird der Benutzer blockiert, etc.) und geben dem Benutzer eine gute Beschreibung, wenn das login fehlschlägt.
Eine Möglichkeit wäre, eine exception zu werfen, aber jemand sagte, dass dies nicht ein richtiger Weg für die Behandlung solcher Situationen.
Jetzt kann ich nur sagen: "Login fehlgeschlagen" oder "Login war erfolgreich", weil der Rückgabetyp bool.
Ist es möglich, um meine eigene ValidateUser-Methode oder muss das ASP.NET die Mitgliedschaft Mechanismus verwendet, das standardmäßig in interne Vorgänge?
- Es ist nicht eine gute Idee zu melden, eine Sperre auf eine web-basierte app, die jeden, der versucht, eine brute-force-Angriff wird wissen, zu stoppen und zu warten, anstatt die Durchführung und potentiell präsentiert das korrekte Passwort auf einem gesperrten Konto und somit keine Zugriff. Nur ein Gedanke für Sie.
- Danke für den Hinweis Lazarus.
- Dies ist ein Manko der MembershipProvider. ValidateUser() nur einen bool zurückgibt, so dass Sie mit SCHLECHTEN Optionen. 1) requery die DB weitere Informationen (overhead), 2) und Methoden hinzufügen Besetzung Ihres providers (das brechen der Unabhängigkeit), oder 3) eine out-of-band-cookie Betrieb. MS sollte die update-Anbieter. Es wäre toll, wenn ValidateUser zurückgegeben, auf ein minimum, und enum AuthenticationStatuts viel wie CreateUser() gibt einen MembershipCreateStatus-enum. Obwohl, ich würde gerne sehen, etwas ein wenig mehr als auch die MembershipCreateStatus enum ist begrenzt (forums.asp.net/t/1521981.aspx).
Du musst angemeldet sein, um einen Kommentar abzugeben.
Das sind zwei verschiedene Vorgänge.
Um zu sehen, ob ein Benutzer genehmigt, gesperrt, etc., look up the user (mit
GetUser()
) und Blick auf dieIsApproved
,IsLockedOut
usw. Eigenschaften der zurückgegebenen Benutzer.ValidateUser()
ist nur für den login, aber man kann beides tun.MembershipUser
anstatt es zu ersetzen, aber bevor Sie das tun, beachten (1) es gibt bereits eine Immobilie soll für den app-spezifischen Daten msdn.microsoft.com/en-us/library/..., und (2) app-spezifische Benutzer-info ist oft besser geeignet für IIdentity als auf eine Mitgliedschaft Benutzer. Die Mitgliedschaft der Benutzer wirklich nur sagen, ob Sie bekommen können in. IIdentity, sagt wer Sie sind.Du kann implementieren alle Methoden, die Sie möchten, um auf Ihre benutzerdefinierten Anbieter, und in Ihrem Fall ist es könnte Sinn, so zu tun und nur cast-Mitgliedschaft zu Ihrem Typ, bevor Sie verwenden.
Aber brechen die Schnittstelle verwenden, um einige einfache out-of-band-info zurück kommen können, beißen Sie in die Zukunft. Es gibt andere Wege, dies zu tun und erhalten die Anbieter-api und halten Sie Ihre Zukunft Optionen offen.
In der Vergangenheit habe ich verwendet ein cookie, um pass out-of-band-Informationen wie diese vom Anbieter an den Verbraucher.
Den HttpContext.Aktuell ist das gleiche für die Anbieter wie für die Seite, so dass ein cookie gesetzt, in dem Anbieter gelesen werden können, in der Verbraucher.
Nur stellen Sie sicher, dass Sie entfernen das cookie nach dem Aufruf von Ihrem provider. Erstellen eines Transienten cookie hilft bei der Minimierung der Fehler, aber nur entfernen Sie es aus der Auflistung sowieso.
Hier ist ein funktionierendes Beispiel.
CookieChannelMembershipProvider
Web.config
Standard.aspx
Müsste man erstellen Sie Ihre eigenen Mechanismus; dies passiert aber nicht standardmäßig aktiviert und kann nicht getan werden, mit der built-in-Mitgliedschaftsanbieter. Sie wickeln konnte, dass Anbieter, und fügen Sie diese Methode und machen Sie es selbst... das ist eine option. Aber dann ist dies nicht im Einklang mit dem login-Steuerelement, wenn Sie es verwenden.