Ich habe dies in den letzten Tagen intensiv recherchiert.

Wir entwickeln eine ASP.Net MVC-Site, die mehr als 100.000 Benutzer unterstützen muss. Wir möchten es schnell, skalierbar und einfach halten. Wir haben eigene SQL-Datenbanktabellen für user und user_role usw. Wir verwenden keine Serversteuerelemente.

Wenn keine Serversteuerelemente vorhanden sind und ein benutzerdefinierter MembershipProvider erstellt werden muss, welche Vorteile bietet die Verwendung von ASP.Net Auth / Membership?

Die andere Alternative scheint darin zu bestehen, benutzerdefinierten Code zu erstellen, um eine UniqueID-Kunden-ID in einem Cookie abzulegen und sich damit zu authentifizieren. Oder, wenn wir paranoid in Bezug auf Schnüffler sind, können wir das Cookie auch verschlüsseln.

Gibt es in diesem Szenario einen echten Vorteil (MVC und Kundendaten befinden sich in unseren eigenen Tabellen) bei der Verwendung des ASP.Net-Authentifizierungs- / Mitgliedschafts-Frameworks, oder ist die vollständig benutzerdefinierte Lösung ein praktikabler Weg?

Update: Ich habe eine Person gefunden (Matt Briggs), die anscheinend zu den gleichen Schlussfolgerungen gelangt ist wie ich: Dies kommt von diesem Link:http: //webcache.googleusercontent.com/search? q = cache: Xm1-OrRCZXIJ: mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=de&gl=us&strip=

ie Mitgliedschaft bei @ ASP.net ist eine schlecht entwickelte API, die von Haus aus unsicher ist, nicht gut gewartet wird und Entwicklern ein falsches Sicherheitsgefühl vermittelt. Authentifizierung ist ein Wochenendprojekt, wenn Sie kein Framework erstellen. Dennoch folgen die meisten .NET-Entwickler blind den offiziellen APIs, vorausgesetzt, ein großes Unternehmen wie MS kann etwas Ordentliches herausbringen.