Encoding issue when parameters are provided by authorization header

[GoogleCodeExporter]

There seems to be a problem with the 0.7.0.0 release when using the 
authorization header to provide the OAuth parameters from a consumer 
application.

Using the exact same code and providing the parameters via query string 
seems to work fine, so it appears to be a bug in the OAuth.Net.Components 
namespace, rather than something specific that I’m doing.

So far, I’ve noticed the problem in two places,  HmacSha1SigningProvider 
and MD5HashVerifierProvider. I get a [signature_invalid] error when 
checking the signature for a request or access token. Similarly, I get a 
[oauth_parameters_rejected, oauth_verifier] error if I implement a hack to 
workaround for the first error.

The errors are thrown from the HmacSha1SigningProvider.CheckSignature and 
MD5HashVerifierProvider.IsValid methods. For example, here’s what I can 
see when debugging the latter method:

verifier => HVlNt2MITzJsPSpkWFy8vw==
hash     => HVlNt2MITzJsPSpkWFy8vw%3D%3D

When using the query string to provide the parameters, the hash correctly 
evaluates to "HVlNt2MITzJsPSpkWFy8vw==" thus allowing things to continue 
as expected.

My guess is there is an issue with the OAuthParameters.ToHeaderFormat 
method and the Rfc3986 encoding – perhaps things are being double-encoded 
(i.e. both inside the ToHeaderFormat method and either before or after the 
method is called).

-Will
will@vertigo.com

Original issue reported on code.google.com by billyz...@yahoo.com on 23 Jul 2009 at 5:05

[GoogleCodeExporter]

This appears to be resolved in the main source trunk now. It's only an issue in 
the 
0.7.0.0 release.

Original comment by billyz...@yahoo.com on 23 Jul 2009 at 10:00

[GoogleCodeExporter]

This issue has already been fixed in the trunk.  No plans to fix on the 0.7.0.0
release branch at the moment - will issue a new relase soon.

Original comment by chris.s....@gmail.com on 24 Jul 2009 at 9:55

• Changed state: Fixed