OAuth en C# en tant que client

Question

m'a donné 6 bits d'informations pour accéder à des données d'un site Web:

1. Site Json Url (par exemple: http://somesite.com/items/list.json)
2. OAuth Autorisation URL (par exemple: http://somesite.com/oauth/authorization)
3. OAuth URL de demande (par exemple: http://somesite.com/oauth/request)
4. accès OAuth URL (par exemple: http://somesite.com/oauth/access)
5. clé client (ex: 12345678)
6. secret client (par exemple: ABCDEFGHIJKLMNOP)

Maintenant, je l'ai regardé dans les bibliothèques et DotNetOpenAuth OAuth.NET, et pendant que je suis sûr qu'ils sont très capables de faire ce que je dois, je ne peux pas comprendre comment utiliser de cette façon.

Quelqu'un pourrait-il publier un exemple de code sur la façon de consommer l'Url (Point 1.) dans l'une ou l'autre bibliothèque (ou de toute autre manière qui pourrait aussi bien fonctionner)?

Merci!

Answer 1

Je viens aussi de commencer à travailler avec OAuth il y a un mois et j'ai aussi été déconcerté par toutes ces bibliothèques. Une chose que j'ai réalisé à propos de ces bibliothèques est qu'elles sont assez compliquées (comme vous l'avez découvert). Une autre chose qui le rend difficile est qu'il n'y avait pas beaucoup d'exemple (c'était pire dans mon cas parce que j'essayais de mettre en place un fournisseur et non un client). A l'origine, je voulais utiliser la dernière OAuth 2.0 mais la seule bibliothèque .NET qui l'implémente est DotNetOpenAuth. C'est probablement l'une des librairies .NET OAuth les plus complètes, mais il me faudra trop de temps pour la comprendre (parce que je ne connais pas le WCF, le MVC, etc.). J'ai depuis rétrogradé à OAuth 1.0a parce que j'ai trouvé ces examples pour DevDefined OAuth. Je ne sais pas pour vous mais j'ai trouvé plus facile d'apprendre des exemples. Il semble que vous ne souhaitiez implémenter qu'un client, alors assurez-vous de consulter les exemples de consommateur. Essayez de compiler les exemples et ignorez les exemples de Provider parce que vous n'en avez pas besoin et cela vous rendra plus confus. Sois patient. Si vous êtes toujours confus, il pourrait être judicieux de regarder certaines des bibliothèques conçues pour d'autres langues, car elles pourraient être plus faciles à comprendre.

Answer 2

Pour OAuth 2.0:

j'ai appris qu'il est plus facile de simplement mettre en place la page d'authentification dans une fenêtre HTML puis piéger le access_token retourné. Vous pouvez ensuite le faire en utilisant un navigateur Web côté client.

Par exemple, dans MonoTouch il serait:

// 
// Present the authentication page to the user 
// 
var authUrl = "http://www.example.com/authenticate"; 
_borwser.LoadRequest (new NSUrlRequest (new NSUrl (authUrl))); 

// 
// The user logged in an we have gotten an access_token 
// 
void Success(string access_token) { 

    _web.RemoveFromSuperview(); 

    var url = "http://www.example.com/data?access_token=" + access_token; 

    // FETCH the URL as needed 
} 

// 
// Watch for the login 
// 
class Del : UIWebViewDelegate 
{ 
    public override void LoadingFinished (UIWebView webView) 
    { 
     try { 
      var url = webView.Request.Url.AbsoluteString; 
      var ci = url.LastIndexOf ("access_token="); 
      if (ci > 0) { 
       var code = url.Substring (ci + "access_token=".Length); 
       _ui.Success (code); 
      } 
     } catch (Exception error) { 
      Log.Error (error); 
     } 
    } 
} 

Answer 3

OK, je sais que votre Dernier message a été mois, mais au cas où vous travailliez encore sur ce (ou pour des gens comme moi qui aurait aimé pour voir une réponse à cette question), voici quelques informations concernant le NullReferenceException que vous avez rencontré lors de la création de la requête OAuth:

La référence null provient du IServiceLocator utilisé pour résoudre les dépendances. Si vous n'en transmettez pas explicitement un dans le constructeur, il utilise la propriété statique ServiceLocator.Current dans l'espace de noms Microsoft.Practices.ServiceLocation.

Ceci est l'un des nombreux pièges de l'utilisation de méthodes statiques et de l'état global, est-ce que vous cachez des problèmes comme celui-ci du consommateur de votre API. Ainsi, si vous n'avez pas spécifié de localisateur de service par défaut, null est renvoyé, ce qui donne le NullReferenceException. Pour résoudre ce problème, j'ai mis en place une implémentation de IServiceLocator qui utilise StructureMap (l'un des nombreux conteneurs IoC disponibles) comme conteneur. Enfin, vous devrez enregistrer des instances pour deux interfaces: ISigningProvider et INonceProvider. Heureusement, plusieurs implémentations standard existent dans l'assembly OAuth.Net.Components, telles que GuidNonceProvider et HmacSha1SigningProvider.

Le code résultant ressemble à quelque chose comme ceci:

var container = new Container(); 

container.Configure(a => a.For<INonceProvider>().Use<GuidNonceProvider>()); 
container.Configure(a => a.For<ISigningProvider>() 
          .Use<HmacSha1SigningProvider>() 
          .Named("signing.provider:HMAC-SHA1")); 

var locator = new StructureMapAdapter(container); 
ServiceLocator.SetLocatorProvider(delegate { return locator; }); 

Je sais que ce n'est pas la solution finale à votre question initiale (je travaille toujours sur l'obtention de moi-même travailler), mais je l'espère vous emmène quelques étapes plus loin. Et si vous avez abandonné depuis longtemps cette implémentation ... eh bien, codage heureux quand même!