Re: [twitter-dev] Re: Streaming API, Basic Auth Ok, OAuth Unauthorized?
On Mon, Oct 25, 2010 at 11:28 PM, themattharris wrote: > Hey everyone, > > So OAuth encoding can get confusing and lead to situations like this > so i'll go through a very verbose walkthrough to hopefully explain how > it all works. First, thank you for taking the time to post this, I agree OAuth can be / is confusing ;) > > The key section of the specification explaining this part is > 3.4.1.3.2: > http://tools.ietf.org/html/rfc5849#section-3.4.1.3.2 > > Assuming my parameters are POST parameters and are as follows: > > key | value > > track | twitter > follow | 1528912,9512582 > oauth_consumer_key | Oauth_Consumer_Key > oauth_nonce | nonce123 > oauth_signature_method | HMAC-SHA1 > oauth_timestamp | 1288042714 > oauth_token | My_tokeN > oauth_version | 1.0 > > Now following 3.4.1.3.2 > 1. Parameter names and values are encoded according to Section 3.6. > Section 3.6 of the spec says: > "The values are then escaped using the [RFC3986] percent-encoding > (%XX) mechanism as follows: > * Characters in the unreserved character set as defined by > [RFC3986], Section 2.3 (ALPHA, DIGIT, "-", ".", "_", "~") MUST NOT be > encoded. > * All other characters MUST be encoded. > * The two hexadecimal characters used to represent encoded > characters MUST be uppercase." > > Knowing this our parameters therefore become: > key | value > > track | twitter > follow | 11528912%2C9512582 > oauth_consumer_key | OauthConsumerKey > oauth_nonce | nonce123 > oauth_signature_method | HMAC-SHA1 > oauth_timestamp | 1288042714 > oauth_token | My_tokeN > oauth_version | 1.0 > > 2. The parameters are sorted by name, using ascending byte value > ordering. If two or more parameters share the same name, they are > sorted by their value. > > key | value > > follow | 11528912%2C9512582 > oauth_consumer_key | OauthConsumerKey > oauth_nonce | nonce123 > oauth_signature_method | HMAC-SHA1 > oauth_timestamp | 1288042714 > oauth_token | My_tokeN > oauth_version | 1.0 > track | twitter > > 3. The name of each parameter is concatenated to its corresponding > value using an "=" character (ASCII code 61) as a separator, even if > the value is empty. > > key=value > > follow=11528912%2C9512582 > oauth_consumer_key=OauthConsumerKey > oauth_nonce=nonce123 > oauth_signature_method=HMAC-SHA1 > oauth_timestamp=1288042714 > oauth_token=My_tokeN > oauth_version=1.0 > track=twitter > > 4. The sorted name/value pairs are concatenated together into a single > string by using an "&" character (ASCII code 38) as separator. Indeed, Steps 1,2, 3 + 4 as described above are the ones I know from the Spec, however on this page: http://dev.twitter.com/pages/auth %3d and %26 are used during the concatenation process, and ... > > follow=11528912%2C9512582&oauth_consumer_key=OauthConsumerKey&oauth_nonce=nonce123&oauth_signature_method=HMAC- > SHA1&oauth_timestamp=1288042714&oauth_token=My_tokeN&oauth_version=1.0&track=twitter > > > This concatenated string of parameters is the result of the > normalization part of 3.4.1.1.5. We still have to complete stage 5 > which says to encode that string. ... This step apparently does not occur ? (again according to that web-page)... it appears that it is considered equivalent to escape the '&' and the '=' during the loop, rather than escape the whole string at once (which will re-escape the individually escaped keys and values as per [I believe] the spec) > > Doing this gives: > follow%3D11528912%252C9512582%26oauth_consumer_key%3DOauthConsumerKey > %26oauth_nonce%3Dnonce123%26oauth_signature_method%3DHMAC- > SHA1%26oauth_timestamp%3D1288042714%26oauth_token%3DMy_tokeN > %26oauth_version%3D1.0%26track%3Dtwitter > > In this example, assuming we are POSTing to > http://stream.twitter.com/1/statuses/filter.json > with the parameters already processed - our basestring becomes: > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses > %2Ffilter.json&follow%3D11528912%252C9512582%26oauth_consumer_key > %3DOauthConsumerKey%26oauth_nonce%3Dnonce123%26oauth_signature_method > %3DHMAC-SHA1%26oauth_timestamp%3D1288042714%26oauth_token%3DMy_tokeN > %26oauth_version%3D1.0%26track%3Dtwitter > > I hope that helps, > @themattharris It will do, if what you say is happening is what *really* happens on the server (and that web page is wrong / or I mis-understand it) .. then I'll have to find some other reason why escaping the url parameters fixes things ;) Cheery-bye, and again, thank you for taking the time to talk this through :) -cj -- 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: Streaming API, Basic Auth Ok, OAuth Unauthorized?
Hey everyone,
So OAuth encoding can get confusing and lead to situations like this
so i'll go through a very verbose walkthrough to hopefully explain how
it all works.
The key section of the specification explaining this part is
3.4.1.3.2:
http://tools.ietf.org/html/rfc5849#section-3.4.1.3.2
Assuming my parameters are POST parameters and are as follows:
key | value
track | twitter
follow | 1528912,9512582
oauth_consumer_key | Oauth_Consumer_Key
oauth_nonce | nonce123
oauth_signature_method | HMAC-SHA1
oauth_timestamp | 1288042714
oauth_token | My_tokeN
oauth_version | 1.0
Now following 3.4.1.3.2
1. Parameter names and values are encoded according to Section 3.6.
Section 3.6 of the spec says:
"The values are then escaped using the [RFC3986] percent-encoding
(%XX) mechanism as follows:
* Characters in the unreserved character set as defined by
[RFC3986], Section 2.3 (ALPHA, DIGIT, "-", ".", "_", "~") MUST NOT be
encoded.
* All other characters MUST be encoded.
* The two hexadecimal characters used to represent encoded
characters MUST be uppercase."
Knowing this our parameters therefore become:
key | value
track | twitter
follow | 11528912%2C9512582
oauth_consumer_key | OauthConsumerKey
oauth_nonce | nonce123
oauth_signature_method | HMAC-SHA1
oauth_timestamp | 1288042714
oauth_token | My_tokeN
oauth_version | 1.0
2. The parameters are sorted by name, using ascending byte value
ordering. If two or more parameters share the same name, they are
sorted by their value.
key | value
follow | 11528912%2C9512582
oauth_consumer_key | OauthConsumerKey
oauth_nonce | nonce123
oauth_signature_method | HMAC-SHA1
oauth_timestamp | 1288042714
oauth_token | My_tokeN
oauth_version | 1.0
track | twitter
3. The name of each parameter is concatenated to its corresponding
value using an "=" character (ASCII code 61) as a separator, even if
the value is empty.
key=value
follow=11528912%2C9512582
oauth_consumer_key=OauthConsumerKey
oauth_nonce=nonce123
oauth_signature_method=HMAC-SHA1
oauth_timestamp=1288042714
oauth_token=My_tokeN
oauth_version=1.0
track=twitter
4. The sorted name/value pairs are concatenated together into a single
string by using an "&" character (ASCII code 38) as separator.
follow=11528912%2C9512582&oauth_consumer_key=OauthConsumerKey&oauth_nonce=nonce123&oauth_signature_method=HMAC-
SHA1&oauth_timestamp=1288042714&oauth_token=My_tokeN&oauth_version=1.0&track=twitter
This concatenated string of parameters is the result of the
normalization part of 3.4.1.1.5. We still have to complete stage 5
which says to encode that string.
Doing this gives:
follow%3D11528912%252C9512582%26oauth_consumer_key%3DOauthConsumerKey
%26oauth_nonce%3Dnonce123%26oauth_signature_method%3DHMAC-
SHA1%26oauth_timestamp%3D1288042714%26oauth_token%3DMy_tokeN
%26oauth_version%3D1.0%26track%3Dtwitter
In this example, assuming we are POSTing to
http://stream.twitter.com/1/statuses/filter.json
with the parameters already processed - our basestring becomes:
POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
%2Ffilter.json&follow%3D11528912%252C9512582%26oauth_consumer_key
%3DOauthConsumerKey%26oauth_nonce%3Dnonce123%26oauth_signature_method
%3DHMAC-SHA1%26oauth_timestamp%3D1288042714%26oauth_token%3DMy_tokeN
%26oauth_version%3D1.0%26track%3Dtwitter
I hope that helps,
@themattharris
On Oct 25, 3:20 pm, "bradley.meck" wrote:
> Correct, I still had the issue when escaping "track=...". Escaping
> params individually did not work either. Still able to tweet though...
> Maybe it is a hint at the trouble being more/different than double
> encoding?
>
> Cheers,
> Bradley
>
> On Oct 25, 4:59 pm, Ciaran wrote:
>
>
>
>
>
>
>
> > On Mon, Oct 25, 2010 at 10:53 PM, bradley.meck
> > wrote:
> > > So in my case i just encodeURIComponent somewhere? I tried on the POST
> > > params and it did not work, nor did the 4 permutations of api-key/
> > > secret and access-token-key/secret.
>
> > Odd, Escaping "track="+tracking.join(",")+"&count=0" should work ?
> > -cj.
--
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: Streaming API, Basic Auth Ok, OAuth Unauthorized?
Correct, I still had the issue when escaping "track=...". Escaping
params individually did not work either. Still able to tweet though...
Maybe it is a hint at the trouble being more/different than double
encoding?
Cheers,
Bradley
On Oct 25, 4:59 pm, Ciaran wrote:
> On Mon, Oct 25, 2010 at 10:53 PM, bradley.meck wrote:
> > So in my case i just encodeURIComponent somewhere? I tried on the POST
> > params and it did not work, nor did the 4 permutations of api-key/
> > secret and access-token-key/secret.
>
> Odd, Escaping "track="+tracking.join(",")+"&count=0" should work ?
> -cj.
--
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: Streaming API, Basic Auth Ok, OAuth Unauthorized?
On Mon, Oct 25, 2010 at 10:53 PM, bradley.meck wrote:
> So in my case i just encodeURIComponent somewhere? I tried on the POST
> params and it did not work, nor did the 4 permutations of api-key/
> secret and access-token-key/secret.
Odd, Escaping "track="+tracking.join(",")+"&count=0" should work ?
-cj.
--
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: Streaming API, Basic Auth Ok, OAuth Unauthorized?
So in my case i just encodeURIComponent somewhere? I tried on the POST params and it did not work, nor did the 4 permutations of api-key/ secret and access-token-key/secret. . On Oct 25, 4:31 pm, Ciaran wrote: > Hey Bradley, > > This is another instance of the the ongoing (and as yet un-answered > sadly) question I have in the mailing list about my client (which > iirc you're using) > > See : > http://github.com/ciaranj/node-oauth/issues#issue/7 > and > http://groups.google.co.uk/group/twitter-development-talk/browse_thre... > oh and also ( :( ) > http://groups.google.co.uk/group/twitter-development-talk/browse_thre... > > The bad news is twitter don't seem to want to tell me if I'm wrong, or > they're wrong (I don't care, just want to know what to fix ! :( ) .. > the good news is the work around is to url encode your parameters > before you pass them off to my client ( you won't need to do this with > any other OAuth provider I've yet come across fwiw, but if they come > back and say yes, thats deliberate, yes its different, I'll hardcode > it into the client so you don't need to worry about it *sigh* (or even > better, the client is wrong, we're right and we do it the same as > everyone else..which would be an ideal outcome) ) > > Take Care > - cj. > > > > > > > > On Mon, Oct 25, 2010 at 10:20 PM, bradley.meck wrote: > > I have a simple oauth client that I use to post status updates > > currently, however, when I added the ability to track statuses with > > the Stream api using OAuth I noticed I could not connect, with > > Unauthorized 401 being the reply to anything I sent it. I looked into > > the documentation and it seems to be a simple request using the same > > OAuth style as the normal api. After searching threads I noticed the > > rate limiting and so I have left my app alone for extended periods of > > time and still I get 401s. I tested against basic auth, and the code > > worked! M, that was odd. So unless I am mistaken I am doing > > something wrong, but I am posting to the right url and mirroring my > > basic auth test to no avail. The code is at: > > >http://github.com/bmeck/Simple-Bot/blob/master/modules/twitter.js > > the track() function is the boilerplate that is in question > > oa.post is a simple rest wrapper for oauth POST. > > > Any help or directions as to where to go from here is much > > appreciated. > > > Cheers, > > Bradley > > > -- > > 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
