FormsAuthentication-Objekt obsolet [mit MVC5]
Ich bin mit dem folgenden code in ein MVC5 Website:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel loginModel) {
if (ModelState.IsValid) {
var authenticated = FormsAuthentication.Authenticate(loginModel.UserName, loginModel.Password);
if (authenticated) {
FormsAuthentication.SetAuthCookie(loginModel.UserName, true);
return RedirectToAction("AdminPanel");
}
ModelState.AddModelError("", "The username and password combination were incorrect");
}
return View(loginModel);
}Das wirft die folgende Warnung:
System.Web.Sicherheit.FormsAuthentication.Authentifizieren(string, string)'
ist veraltet: 'Die empfohlene alternative ist die Nutzung der Mitgliedschaft
APIs, wie zum Beispiel die Mitgliedschaft.ValidateUser. Weitere Informationen finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=252463.'
Zuerst ein disclaimer - ich bin einer der Entwickler, die gerne up to date halten mit den Dingen, und ich bevorzuge es, zu vermeiden, Warnungen in VS komplett. Allerdings, in diesem speziellen Fall, ich bin mit extrem primitiv, die Authentifizierung, die kommt direkt aus dem web.config wie folgt:
<authentication mode="Forms">
<forms loginUrl="~/account/login" timeout="2880" slidingExpiration="true" name=".ASPXFORMSAUTH">
<credentials passwordFormat="SHA1">
<user name="MyUserName" password="a-big-long-password-hash"/>
</credentials>
</forms>
</authentication>Es gibt absolut keine weiteren login-Anforderungen in diesem Projekt mit Hilfe einer Datenbank ist übertrieben, und es gibt keine Notwendigkeit für verteilte anmelden; grundsätzlich ist die Speicherung der Informationen im web.config ist die ideale Lösung, und es wird wahrscheinlich nur ein Benutzer pro Anwendung. Ich werde ohne Zweifel die abstrakte authentication code aus dem controller (mit DI /IoC), aber ich bin immer noch beabsichtigte Verwendung der FormsAuthentication-Objekt zu authentifizieren, die details im web.config.
Ich bin mir zwar durchaus bewusst, Mitgliedschaft Anbieter, DotNetOpenAuth und die neue (aber ziemlich schrecklich imo) OWIN basierte Authentifizierung-Modell der obige code ist mehr als ausreichend.
Erste Frage - Warum hat FormsAuthentication schon veraltet, wenn das ist eine vollkommen gültige use-case? Ich verstehe, dass FormsAuthentication ist eine geschlossene black box, ist schwer zu testen, und der code dahinter ist es, domain-spezifische, aber in diesem besonderen Fall (wo will ich Lesen Sie details direkt aus dem Abschnitt der web.config), es scheint Wahnsinn zu schreiben, eine Mitgliedschaft oder eine benutzerdefinierte Authentifizierung-service?
Zweite Frage - es sei denn, ich bin fehlt etwas, die neue OWIN-Modell für die verteilte Authentifizierung und ist nicht geeignet für eine Rolle, enterprise-level-security-system. Aus den vielen blog-Beiträge, white papers und SO Beiträge, die ich gelesen habe, scheint es auch wie es ist immer noch unvollständig. Bin ich richtig in meinen Annahmen? Ist OWIN die Zukunft aller security-Systeme, oder sollte ich weiter schreiben, maßgeschneiderte security-Systeme besser geeignet für meine Bedürfnisse der Klienten?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Zu Ihrem ersten Punkt, den wir überholt haben, weil es ist völlig unzureichend, die von modernen Sicherheits-standards. Es verwendet einen geraden hash ohne iteration, was bedeutet, dass jeder, der Zugriff auf Ihr Web.config können leicht herausfinden, was die eigentlichen Passwörter wurden. Aber wenn Sie bereit sind, diese Risiken akzeptieren, können Sie natürlich weiterhin verwenden, gehen nach vorne. Nur unterdrückt die Warnung und solider auf mit deinem original-code.
Zu Ihrem zweiten Punkt, es gibt keinerlei Verbindung zwischen diesem und OWIN.
Hoffe, das klärt es auf!
OWIN ist nicht nur um die Sicherheit. Es ist ein standard, der definiert, die Schnittstellen zwischen einer Anwendung, die framework - (ASP.NET MVC) und web server (IIS). Es ist eine neue Ebene der Abstraktion Microsoft definiert zu lassen .NET-Entwickler Anwendungen schreiben, die host-agnostisch, d.h. nicht abhängig von IIS.
OWIN-Architektur ist eine pipeline, die aus mehreren middleware-Komponenten. In MVC5, security wurde von Grund auf neu geschrieben als OWIN-middleware-Komponente. Wenn dies nicht funktioniert für Sie und Sie wollen, Rollen Sie Ihre eigenen Passwort-Verifizierungs-routine, die Sie implementieren können, die Ihre eigenen Sicherheits-middleware. Hier ist ein post beschreiben, wie es zu tun.
Wenn Sie nicht wollen, so weit zu gehen, diese post zeigt, wie verlassen sich auf die integrierte authentication framework, ohne die Mitgliedschaft
Alles, was Levi erwähnt wird, ist immer noch gültig, obwohl. Sie wollen, vorsichtig zu sein mit Ihrem eigenen Hash/Speicher-Mechanismus und wählen Sie ein guter Hash-Algorithmus.
Hier etwas mehr hintergrund-info über OWIN Sicherheit midddleware von Microsoft implementiert.