oauth_verifier is not passed using DotNetOpenAuth's Webconsumer

I receive back a good oauth_verifier value from the server, but it is not being passed on via the ProcessUserAuthorization call to the access_token endpoint.

I'm using DotNetOpenAuth 3.3.1, and the WebConsumer implementat开发者_如何学JAVAion. The server I'm working with is using OAuth 1.0a not 1.0.1.

Do I need to force DotNetOpenAuth to use 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>

A pastebin link to the log4net log

---

If you look at the log, you'll see that DotNetOpenAuth received the verifier message and recognized it as a 1.0a message where the log says "received UserAuthorizationResponse (1.0.1)" (since 1.0.1 is DNOA's way of saying 1.0a).

You'll also note from the log that DNOA sends a "AuthorizedTokenRequest (1.0)" message. This strongly suggests that the ServiceProviderDescription object that you've passed to the WebConsumer instance with a ProtocolVersion property set to V10 instead of V10a.

You may be initializing the ServiceProviderDescription correctly when you first send the user to the Service Provider, but initializing it without setting its version number the second time when you call WebConsumer.ProcessAuthorization.

Another possibility is that the Service Provider is violating the OAuth 1.0a spec, and DotNetOpenAuth detects this and overrides your setting and decides to treat the service provider as merely an OAuth 1.0 service provider. If this is what's happening, you see your own ServiceProviderDescription object's ProtocolVersion property change from 1.0.1 to 1.0, and your log will include this substring "Expected OAuth service provider at endpoint"...