Re: [twitter-dev] Re: can't follow more than one user
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
Re: [twitter-dev] Re: can't follow more than one user
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
[twitter-dev] Re: can't follow more than one user
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 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-dev] Re: can't follow more than one user
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 against http://oauth.net/core/1.0a/ Sec. 9.1.1 and even double checked against http://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 at http://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
