Benötige ich einen benutzerdefinierten Mitgliedschaftsanbieter, um die Authentifizierung von Drittanbietern in ASP.NET zu integrieren?

Question

Ich habe eine ASP.NET MVC-Anwendung, in die ich gerade das RPX Drittanbieter-System föderierter Identität integriert habe. Die Integration funktioniert gut, aber ich habe einige Schwierigkeiten, meinen Kopf darauf zu legen, was damit auf ASP.NET-Ebene zu tun ist.

Ich bin ziemlich neu in ASP.NET (ich lerne es mit MVC), und ich habe ein wenig über das Providermodell für Mitgliedschaft und Profildaten entdeckt, und es scheint unglaublich komplex (aber ebenso leistungsstark). Die spezifische Sache, mit der ich zu kämpfen habe, ist die Persistenz des Benutzers in der Datenbank. Ich habe bisher die Standard SqlMembershipProvider Implementierung verwendet, die gut funktioniert hat. Ich möchte nun jedoch einen Bestätigungscode in der Datenbank speichern und überprüfen, um die E-Mail-Überprüfung zu bestätigen (falls die E-Mail-Adresse des Benutzers vom RPX-Ergebnis als nicht bestätigt angezeigt wird) und die zurückgegebenen Daten beizubehalten. Einige davon sind für die Authentifizierung wichtig, z. B. die E-Mail-Adresse, während es sich bei einigen nur um Profilinformationen handelt (wie Alter, Geschlecht usw.).

In der ASP.NET-Datenbank habe ich eine Reihe anderer App-spezifischen Tabellen, mit denen ich über NHibernate interagiere. Mein Verständnis der Mitgliedschaft/Profil-Sachen in ASP.NET ist, dass es die Persistenz behandelt, und so muss ich nichts mit NHibernate tun, um dies zu erreichen.

Mein Ziel ist, dass die Anmeldeerfahrung mit StackOverflow vergleichbar ist, aber mit einigen zusätzlichen Bits (z. B. E-Mail-Verifizierung). Muss ich einen vollständigen benutzerdefinierten Anbieter erstellen, um dies zu tun, oder kann ich den Standard SqlMembershipProvider meinem Willen auf effektive Weise verbiegen?

[Bitte beachten Sie auch my other question sehen, in Bezug auf Passwörter in einer solchen Anwendung.]

Answer 1

ich eine ähnliche Arbeit in der Vergangenheit gerade einen neuen Provider-Klasse, indem die von SqlMembershipProvider erbt getan haben, dann die Methoden überschreiben muss ich .

Sie können immer noch die Basismethodenimplementierung aufrufen, um die meiste Arbeit zuerst auszuführen, und dann die zusätzliche Logik ausführen, die Sie in Ihrer abgeleiteten Klasse benötigen. Einen Provider von Grund auf neu aufzubauen ist eine Menge Arbeit und sollte nur Ihr letzter Ausweg sein.

Sie können der Datenbank eine neue Tabelle mit einem Schlüsselverweis auf aspnet_Membership hinzufügen - dann fügen Sie Ihre eigenen gespeicherten Prozeduren hinzu, die Sie von Ihren abgeleiteten Providermethoden aufrufen, um alles zu tun, was Sie für diese neue Tabelle benötigen. Dies ist besser als das Hinzufügen von Spalten zum Mitgliedschaftsschema, da dadurch Ihre benutzerdefinierten Elemente entkoppelt bleiben.

Sie müssen noch die SqlMembershipProvider-Klasse untersuchen, in Bezug darauf, was Sie überschreiben müssen, aber ich denke, dass dieser Ansatz für Sie auf der Grundlage Ihrer Beschreibung funktioniert.