OAuth в C#, как клиент

Question

я был дан 6 бит информации для доступа к некоторым данным с сайта:

1. Сайт Json URL (например: http://somesite.com/items/list.json)
2. OAuth URL авторизации (например: http://somesite.com/oauth/authorization)
3. OAuth URL запроса (например: http://somesite.com/oauth/request)
4. OAuth Доступ в URL (например: http://somesite.com/oauth/access)
5. Client Key (например: 12345678)
6. Client Secret (например: ABCDEFGHIJKLMNOP)

Теперь я смотрел на DotNetOpenAuth и OAuth.NET библиотек, и в то время как я уверен, что они очень способны делать то, что мне нужно, я просто не могу понять как пользоваться этим способом.

Может ли кто-нибудь опубликовать некоторый пример кода о том, как использовать Url (пункт 1.) в любой библиотеке (или любым другим способом, который может работать так же хорошо)?

Спасибо!

Answer 1

Я также начал работать с OAuth месяц назад и был также смущен всеми этими библиотеками. Единственное, что я понял об этих библиотеках, это то, что они довольно сложны (как вы выяснили). Еще одна вещь, которая усложняет ее, заключается в том, что примера не было (это было хуже в моем случае, потому что я пытался реализовать поставщика, а не клиента).

Первоначально я хотел использовать последнюю версию OAuth 2.0, но единственную библиотеку .NET, которая реализует ее, - это DotNetOpenAuth. Вероятно, это одна из самых полных библиотек .NET OAuth, но для меня это займет слишком много времени (из-за незнания WCF, MVC и т. Д.). С тех пор я отказался от OAuth 1.0a, потому что нашел эти examples для DevDefined OAuth. Я не знаю о вас, но мне было легче учиться на примерах.

Похоже, вы только хотите реализовать клиента, поэтому обязательно посмотрите примеры потребителей. Попытайтесь скомпилировать примеры и проигнорировать примеры поставщиков, потому что они вам не нужны, и это сделает вас более запутанными. Потерпи. Если вы все еще запутались, может быть хорошей идеей взглянуть на некоторые из библиотек, созданных для других языков, поскольку им может быть легче понять документацию.

Answer 2

Для OAuth 2.0:

я узнал, что это легче всего просто поставить страницу аутентификации в HTML-окна, а затем ловушку возвращаемый access_token. Затем вы можете использовать это в клиентском браузере.

Например, в MonoTouch было бы:

// 
// 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

ОК, я знаю, что ваш последний пост было несколько месяцев назад, но в случае, если вы все еще работаем над этим (или для людей вроде меня, кто бы любил чтобы увидеть ответ на этот вопрос), вот некоторая информация о , с которой вы столкнулись при создании запроса OAuth:

Нулевая ссылка взята из IServiceLocator, которая используется для разрешения зависимостей. Если вы явно не передаете один в конструктор, он использует статическое свойство ServiceLocator.Current в пространстве имен Microsoft.Practices.ServiceLocation.

Это одна из многих подводных камней использования статических методов и глобального состояния, вы скрываете подобные проблемы у потребителя вашего API. Поэтому, если вы не указали локатор службы по умолчанию, возвращается null, в результате чего получается NullReferenceException.

Чтобы исправить эту проблему, я подключил реализацию IServiceLocator, в которой используется StructureMap (один из множества доступных контейнеров IoC) в качестве контейнера. Наконец, вам нужно будет зарегистрировать экземпляры для двух интерфейсов: ISigningProvider и INonceProvider. К счастью, в сборке OAuth.Net.Components имеется несколько стандартных реализаций, таких как GuidNonceProvider и HmacSha1SigningProvider.

Результирующий код выглядит как что-то вроде этого:

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; }); 

Я понимаю, что это не окончательное решение к первоначальному вопросу (я все еще работаю над его работать самостоятельно), но я надеюсь, что это еще несколько шагов. И если вы уже давно отказались от этой реализации ... ну, счастливая кодировка!