Stuck mit Microsoft.Web.WebPages.OAuth.OAuthWebSecurity in einer MVC-Anwendung

Question

Ich verstehe nur einige Code im Microsoft.Web.WebPages.OAuth Namespace, speziell die OAuthWebSecurity Klasse.

Es ist diese Methode hier: -

internal static void RequestAuthenticationCore(HttpContextBase context, 
    string provider, string returnUrl) 
{ 
    IAuthenticationClient client = GetOAuthClient(provider); 
    var securityManager = new OpenAuthSecurityManager(context, 
     client, OAuthDataProvider); 
    securityManager.RequestAuthentication(returnUrl); 
} 

Die erste Zeile ist in Ordnung => die Provider-Daten greifen, für diese Authentifizierungsanforderung. Lass uns so tun, als wäre dies ein TwitterClient(..).

Jetzt müssen wir eine SecurityManager Klasse erstellen, die drei Argumente akzeptiert. Was ist das dritte Argument? Ein OAuthDataProvider? Das ist als eine statische definiert, hier:

internal static IOpenAuthDataProvider OAuthDataProvider = 
    new WebPagesOAuthDataProvider(); 

Und das schafft eine WebPagesOAuthDataProvider. Das ist mein Problem. Was ist das? Und warum muss es eng an eine ExtendedMembershipProvider gekoppelt sein? Was ist ein ExtendedMembershipProvider? Warum ist das nötig?

In meiner Webanwendung versuche ich eine RavenDb-Datenbank und meine eigene benutzerdefinierte Principal und benutzerdefinierte Identität zu verwenden. Nichts zu tun mit Mitgliedschaft oder SimpleMembership, die mit ASP.NET kommt.

Könnte mir bitte jemand hier helfen? Was ist diese Klasse und warum wird sie benutzt? Was ist der Zweck? Ist das etwas, das DNOA erfordert? und warum?

(Ich hoffe auch heimlich, dass Andrew Arnott dieses Q sehen und mir helfen wird).

Answer 1

Ich habe den von Ihnen erwähnten Code nicht geschrieben, daher könnte ich hier falsch liegen, aber ich glaube, der ASP.NET-Code, auf den Sie verweisen, ist in der Tat an seinen Mitgliedschaftsanbieter gebunden.

Wenn Sie nicht den ASP.NET-Mitgliedschaftsanbieter verwenden, würde ich vorschlagen, dass Sie einfach DotNetOpenAuth direkt verwenden (im Gegensatz zu der Fassade, die Microsoft hinzugefügt hat), die keine so enge Kopplung hat.

Answer 2

Wenn Sie das ASP.NET-Mitgliedschaftssystem nicht benötigen, um lokale Anmeldekonten (Konten, die in Ihrer lokalen Mitgliedschaftsdatenbank gespeichert sind) auf Ihrem System bereitzustellen, würde ich nicht den Weg der Verwendung von WebMatrix-basierten Bits gehen (WebSecurity/OAuthWebSicherheit).

Sie tatsächlich machen es schwieriger mit DNOA zu interagieren und mehr oder weniger verbergen alle interessanten Bits zugleich sowieso ...

Als ich lokale acounts benötigt endete ich für all das den Quellcode nach oben ziehen in meinen Quellcode und dann von dort aus bearbeiten (ich hatte auch andere Gründe, dies nicht nur um die Interaktion mit DNOA zu bereichern). Wenn Sie lokale Konten benötigen, verwenden Sie WebMatrix Wenn Sie keine lokalen Konten benötigen, verwenden Sie DNOA direkt.