oauth_verifier не передается с помощью веб-клиента DotNetOpenAuth

Question

Я получаю обратно хорошее значение oauth_verifier с сервера, но оно не передается через ProcessUserAuthorization вызов конечной точке access_token.

Я использую DotNetOpenAuth 3.3.1 и реализацию WebConsumer. Сервер, с которым я работаю, использует OAuth 1.0a, а не 1.0.1.

Нужно ли заставлять DotNetOpenAuth использовать 1.0a?

2010-01-16 13:19:44,343 [5] DEBUG DotNetOpenAuth.Messaging.Channel [(null)] <(null)> - After binding element processing, the received UserAuthorizationResponse (1.0.1) message is: 
    oauth_verifier: dEz9lE9AA1gcdr6oCbmD
    oauth_token: vauHNVOCITlbGCuqycWn

2010-01-16 13:19:44,346 [5] DEBUG DotNetOpenAuth.Messaging.Channel [(null)] <(null)> - Preparing to send AuthorizedTokenRequest (1.0) message.
2010-01-16 13:19:44,346 [5] DEBUG DotNetOpenAuth.Messaging.Bindings [(null)] <(null)> - Binding element DotNetOpenAuth.OAuth.ChannelElements.OAuthHttpMethodBindingElement applied to message.
2010-01-16 13:19:44,346 [5] DEBUG DotNetOpenAuth.Messaging.Bindings [(null)] <(null)> - Binding element DotNetOpenAuth.Messaging.Bindings.StandardReplayProtectionBindingElement applied to message.
2010-01-16 13:19:44,346 [5] DEBUG DotNetOpenAuth.Messaging.Bindings [(null)] <(null)> - Binding element DotNetOpenAuth.Messaging.Bindings.StandardExpirationBindingElement applied to message.
2010-01-16 13:19:44,346 [5] DEBUG DotNetOpenAuth.Messaging.Channel [(null)] <(null)> - Applying secrets to message to prepare for signing or signature verification.
2010-01-16 13:19:44,348 [5] DEBUG DotNetOpenAuth.Messaging.Bindings [(null)] <(null)> - Signing AuthorizedTokenRequest message using HMAC-SHA1.
2010-01-16 13:19:44,349 [5] DEBUG DotNetOpenAuth.Messaging.Bindings [(null)] <(null)> - Constructed signature base string: GET&http%3A%2F%2Fx-staging.indivo.org%3A8000%2Foauth%2Faccess_token&oauth_consumer_key%3Doak%26oauth_nonce%3DgPersiZV%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1263676784%26oauth_token%3DvauHNVOCITlbGCuqycWn%26oauth_version%3D1.0
2010-01-16 13:19:44,349 [5] DEBUG DotNetOpenAuth.Messaging.Bindings [(null)] <(null)> - Binding element DotNetOpenAuth.OAuth.ChannelElements.SigningBindingElementChain applied to message.
2010-01-16 13:19:44,351 [5] INFO  DotNetOpenAuth.Messaging.Channel [(null)] <(null)> - Prepared outgoing AuthorizedTokenRequest (1.0) message for http://x-staging.indivo.org:8000/oauth/access_token: 
    oauth_token: vauHNVOCITlbGCuqycWn
    oauth_consumer_key: XXXXXXmyComsumerKeyXXXXXX
    oauth_nonce: gPersiZV
    oauth_signature_method: HMAC-SHA1
    oauth_signature: xNynvr2oFlqtdoOKOl2ETiiTLGY=
    oauth_version: 1.0
    oauth_timestamp: 1263676784

2010-01-16 13:19:44,351 [5] DEBUG DotNetOpenAuth.Messaging.Channel [(null)] <(null)> - Sending AuthorizedTokenRequest request.
2010-01-16 13:19:44,351 [5] DEBUG DotNetOpenAuth.Http [(null)] <(null)> - HTTP GET http://x-staging.indivo.org:8000/oauth/access_token
2010-01-16 13:20:34,657 [5] ERROR DotNetOpenAuth.Http [(null)] <(null)> - WebException from http://x-staging.indivo.org:8000/oauth/access_token: 
<h4>Internal Server Error</h4>

Вставная ссылка на журнал log4net

Answer 1

Если вы посмотрите на журнал, вы увидите, что DotNetOpenAuth получил сообщение верификатора и распознал его как сообщение 1.0a, где в журнале говорится «полученный UserAuthorizationResponse (1.0.1)» (поскольку 1.0.1 - это способ DNOA говоря 1.0a).

Вы также заметите из журнала, что DNOA отправляет сообщение «AuthorizedTokenRequest (1.0)». Это настоятельно предполагает, что объект ServiceProviderDescription, который вы передали в экземпляр WebConsumer со свойством ProtocolVersion, установленным на V10 вместо V10a.

Вы можете правильно инициализировать ServiceProviderDescription при первой отправке пользователя поставщику услуг, но при его инициализации без установки номера версии во второй раз при вызове WebConsumer.ProcessAuthorization.

Другая возможность заключается в том, что поставщик услуг нарушает спецификацию OAuth 1.0a, и DotNetOpenAuth обнаруживает это и переопределяет ваши настройки и решает рассматривать поставщика услуг как просто поставщика услуг OAuth 1.0. Если это именно то, что происходит, вы увидите, что ваше собственное свойство ServiceProviderDescription объекта ProtocolVersion изменилось с 1.0.1 на 1.0, и ваш журнал будет содержать эту подстроку "Ожидаемый поставщик услуг OAuth в конечной точке" ...