I just wanted to note the resolution to the issue. My problem was actually in the way I was reading the spec, so I wanted to bring it up in case the spec should be clarified.
Sections 9.2.1 and 9.4.1 talk about how the signature is calculated, base64-encoded, then OAuth-percent-encoded. When I read this, I assumed that the way you calculated the signature value was by following (all of) these 3 steps. Then, section 5 talks about how the OAuth parameters are OAuth-percent- encoded. I read this to mean that the signature value as defined by sections 9.2.1 and 9.4.1, since it's an OAuth parameter, was AGAIN percent-encoded when passed in the Authorization Header/GET params/ POST params. Note that the result of the base64-encoded signature was being encoded twice. But the other OAuth libraries don't seem to be doing that. It seems that the signature value is actually just the base64-encoded value of the signature calculation. The OAuth-percent-encode step was just added for redundancy. Since the OAuth-percent-encode operation is idempotent, it wasn't the client-side that was causing a problem. The problem came when attempting to validate the signature on the provider-side. The (assumed) steps were reversed, OAuth-percent-decoding the parameters, then again OAuth-percent-decoding the signature value before base64- decoding it and verifying it. The problem surfaces when OAuth-percent-decoding a value with a "+" character in it. All the standard percent-decoding libraries decode the "+" character into a " " character. So the verification of the signature failed. Anyway, take the story for what it's worth. Just for the record. Thanks, -Ryan On Dec 3, 12:40 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Encoding seems to be handled by OAuth.percentEncode / > OAuth.formEncode / OAuth.addParameter which are called in > OAuthClient.invoke() > > If you write a subclass of OAuthClient you should be fine, if you > write your own client you have to encode yourself. > > Note that all parameters have to be encoded prior to computing the > signature but this is done in HMAC_SHA1.computeSignature() > > --Gilles > > On Dec 3, 10:52 am, Ryan Heaton <[EMAIL PROTECTED]> wrote: > > > Hi. > > > There's an inconsistency with the implementation of HMAC_SHA1 > > signature method in the OAuth Java Libraries (Google Code). The spec > > says the signature is "the calculated digest octet string, first > > base64-encoded per [RFC2045] section 6.8, then URL-encoded per > > Parameter Encoding" (see section 9.2.1). The OAuth Java library does > > the first part (base-64 encodes the bytes) but neglects the second > > part (URL-encoding it). > > > This means, for example, that the OAuth Java library calculates a > > signature to be > > > 4KaVKEnW6e1a+vwJTpz0VFqIaGU= > > > when it should be > > > 4KaVKEnW6e1a%2BvwJTpz0VFqIaGU%3D > > > Am I reading the spec wrong? Or is this a bug? > > > -Ryan > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
