Bloccato utilizzando Microsoft.Web.WebPages.OAuth.OAuthWebSecurity in un'applicazione MVC

Question

Non capisco alcun codice nello spazio dei nomi Microsoft.Web.WebPages.OAuth, in particolare nella classe OAuthWebSecurity.

E 'questo metodo qui: -

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

La prima linea è bene => afferrare i dati del provider, per questa richiesta di autenticazione. Supponiamo che questo sia un TwitterClient(..).

Ora, dobbiamo creare una classe SecurityManager .. che accetta tre argomenti. Cos'è quel terzo argomento? An OAuthDataProvider? Questo è definito come una statica, qui:

internal static IOpenAuthDataProvider OAuthDataProvider = 
    new WebPagesOAuthDataProvider(); 

e questo crea un WebPagesOAuthDataProvider. Questo è il mio problema. Cos'è questo? E perché deve essere strettamente accoppiato a un ExtendedMembershipProvider? Che cos'è un ExtendedMembershipProvider? Perché è necessario?

Nella mia applicazione Web sto provando a utilizzare un database RavenDb e il mio principal personalizzato e identità personalizzata. Niente a che vedere con Membership o SimpleMembership fornito con ASP.NET.

Qualcuno potrebbe aiutarmi a venire qui? Cos'è questa classe e perché viene usata, ecc.? Qual è il suo scopo? È qualcosa che richiede DNOA? e perché?

(spero anche che Andrew Arnott vedrà questo Q e mi aiuti).

Answer 1

Non ho scritto il codice che hai citato, quindi potrei sbagliarmi qui, ma credo che il codice ASP.NET a cui fai riferimento sia effettivamente associato al loro provider di appartenenza.

Se non si utilizza il provider di appartenenze ASP.NET, suggerirei di utilizzare semplicemente DotNetOpenAuth direttamente (a differenza della facciata che Microsoft ha aggiunto), che non ha un accoppiamento così stretto.

Answer 2

Se non è necessario il sistema di appartenenza ASP.NET per fornire account di accesso locali (account memorizzati nel database di appartenenza locale) sul proprio sistema, non utilizzerò il percorso di utilizzare alcun bit basato su WebMatrix (WebSecurity/OAuthWebSecurity).

Essi in realtà rendono più difficile per interagire con DNOA e più o meno nascondere tutti i bit interessanti allo stesso tempo comunque ...

Come avevo bisogno Acounts locali ho finito per tirare tutto il codice sorgente per questo in il mio codice sorgente e poi modificarlo da lì (ho avuto anche altre ragioni per farlo, non solo per arricchire l'interazione con DNOA).

Se sono necessari account locali, utilizzare WebMatrix Se non sono necessari account locali, utilizzare direttamente DNOA.