[SiteStreams] can't follow more than one user

[Ruben Fonseca]

Hi @all!

Not sure if I'm posting to the correct list, but here it goes.

I'm currently trying to migrate a website service that uses
UserStreams to SiteStreams, as the documentation tells me to do.

However I'm finding a difficult problem that I've been able to
reproduce:

If I try to follow 1 user_id, it works ok. If I try to follow 2 or
more, SiteStreams always answers 401 Unauthorized.

Example: (Host: betastream.twitter.com)

- this works
GET /2b/site.json?with=followings&follow=11528912 HTTP/1.1

- this works too
GET /2b/site.json?with=followings&follow=9512582 HTTP/1.1

- this always returns 401 UNAUTHORIZED
GET /2b/site.json?with=followings&follow=11528912,9512582 HTTP/1.1

Any thing I'm missing here? Thank you!

[Thomas Mango]

Hey, Ruben. That's the correct URL format. Are you sure your account was
approved for Site Stream access?

--
Thomas Mango
tsm...@gmail.com

[Ruben Fonseca]

Hi Thomas

On Oct 6, 5:20 pm, Thomas Mango <tsma...@gmail.com> wrote:
> Hey, Ruben. That's the correct URL format. Are you sure your account was
> approved for Site Stream access?

Yes it is, I filled all forms and received confirmation on monday.
Maybe I'm wrong, but the fact that it works with only one person to
follow proves that I have access to SiteStreams.

Anyways my username is 'rubenfonseca' (no quotes). I'm using an OAuth
token from that user on my application.

Thank you!

[John Kalucki]

It might be an OAuth encoding error with the ','. Which OAuth library
are you using?

-John

> --
> 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
>

[Ruben Fonseca]

Hi John!

On Oct 6, 5:54 pm, John Kalucki <j...@twitter.com> 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 here
http://github.com/ciaranj/node-oauth/) and realized the signature was
being generated wrong.

Patched the library and it now works great!! Thank you!!!

[JavaJunky]

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 <fons...@gmail.com> wrote:
> Hi John!
>
> On Oct 6, 5:54 pm, John Kalucki <j...@twitter.com> 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

[Malte]

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 <ciar...@gmail.com> 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

[Ciaran]

On Thu, Oct 7, 2010 at 10:04 PM, Malte <malt...@gmail.com> 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

[Ciaran]

Ah you *are* that other user! Doh :)
- cj