Ah you *are* that other user! Doh :)
- cj
On Thursday, October 7, 2010, Ciaran wrote:
> On Thu, Oct 7, 2010 at 10:04 PM, Malte wrote:
>> Hi,
>>
>> because I'm using the same library and was not finding the same
>> problems when connecting to site streams I looked for what I was doing
>> differently: Turns out, if one URL encodes the komma in the follow
>> list the OAuth connection works
>>
>> Bye
>> Malte
>
> Hi,
>
> Yes, another user reported this as a workaround too, I'd still like
> some clarification from t'twitter as to whether the client is wrong
> (my current plan will be to 'if-twitter' around the signing code ;) )
>
> Thanks for the heads up though!
>
> -cj
>
>>
>> On 6 Oct, 23:38, JavaJunky wrote:
>>> Hi,
>>>
>>> The library in question is mine and not unreasonably Ruben has
>>> submitted a pull-request with his fix over on github. Unfortunately
>>> this fix seems to break existing (working) OAuth consumer
>>> relationships :(
>>>
>>> I'm actually at a bit of a loss how to progress it, I've
>>> read:http://dev.twitter.com/pages/auth(Signing Requests) a few times.
>>> I've cross-referenced againsthttp://oauth.net/core/1.0a/Sec. 9.1.1
>>> and even double checked
>>> againsthttp://tools.ietf.org/html/rfc5849#section-3.4.1
>>> Sec. 3.4.1.3.2
>>>
>>> The last two resources appear to agree with each other, that the '='
>>> and the '&' that join the parameter name-value pairs should appear in
>>> the 'plain' but then get encoded as a whole [which would re-encode any
>>> existing '%', hence a crucial difference in the twitter listed
>>> strategy]
>>>
>>> The important bit seems to be in the OAuth 1.0 RFC Section 3.4.1.1.
>>> String Construction, point 5:
>>>
>>> 5. The request parameters as normalized in Section 3.4.1.3.2,
>>> after
>>> being encoded (Section 3.6).
>>>
>>> Crucially this suggests to me that that the encoding is applied to the
>>> entire normalized string, which the documentation
>>> athttp://dev.twitter.com/pages/auth
>>> seems to suggest isn't happening on the Twitter side :(
>>>
>>> It is (more than likely) entirely possible that I'm doing something
>>> incredibly stupid and obvious but is there anyone on the twitter side
>>> that can confirm that this deviation from the 'spec' is deliberate (or
>>> even better for consistency, a minor issue?)
>>>
>>> Many Thanks (and sorry if I'm wasting your time!)
>>> - Cj.
>>>
>>> On Oct 6, 6:31 pm, Ruben Fonseca wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> > Hi John!
>>>
>>> > On Oct 6, 5:54 pm, John Kalucki wrote:
>>>
>>> > > It might be an OAuth encoding error with the ','. Which OAuth library
>>> > > are you using?
>>>
>>> > That was exactly the problem! I was using node-oauth (from
>>> > herehttp://github.com/ciaranj/node-oauth/) and realized the signature was
>>> > being generated wrong.
>>>
>>> > Patched the library and it now works great!! Thank you!!!
>>
>> --
>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>> API updates via Twitter: http://twitter.com/twitterapi
>> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
>> Change your membership to this group:
>> http://groups.google.com/group/twitter-development-talk
>>
>
--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
http://groups.google.com/group/twitter-development-talk
