On Aug 12, 8:52 am, Tom van der Woerdt <i...@tvdw.eu> wrote:
> On 8/12/10 2:37 PM, bear wrote:
>
>
>
>
>
> > On Aug 12, 7:57 am, Tom van der Woerdt <i...@tvdw.eu> wrote:
> >> On 8/12/10 1:33 PM, bear wrote:
>
> >>> I'm working on bringing the python-twitter library up to date with
> >>> respect to using oAuth and i'm running into a brick wall...
>
> >>> I've scanned the group postings and by far it seems that the most
> >>> common issue when generating a request is that the order of items in
> >>> the url param list is not the same as the order of items sent off to
> >>> be signed *and* that said item list must be sorted.
>
> >>> Using the debug key/secret values from the wiki, I generate the
> >>> following:
>
> >>> (debug output from python's urllib2, formatted to wrap so it's
> >>> readable)
> >>> GET /1/account/verify_credentials.json?
> >>> oauth_nonce=26979601&
> >>> oauth_timestamp=1281612120&
> >>> oauth_consumer_key=GDdmIQH6jhtmLUypg82g&
> >>> oauth_signature_method=HMAC-SHA1&
> >>> oauth_version=1.0&
> >>> oauth_token=819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw&
> >>> oauth_signature=e82GTcQn9Rjir1QMNw19%2FwTkAYA%3D
> >>> HTTP/1.1\r\n
> >>> Accept-Encoding: identity\r\n
> >>> Host: api.twitter.com\r\n
> >>> Connection: close\r\n
> >>> Authorization: OAuth realm="", oauth_nonce="26979601",
> >>> oauth_timestamp="1281612120",
> >>> oauth_consumer_key="GDdmIQH6jhtmLUypg82g",
> >>> oauth_signature_method="HMAC-SHA1", oauth_version="1.0",
> >>> oauth_token="819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw",
> >>> oauth_signature="e82GTcQn9Rjir1QMNw19%2FwTkAYA%3D"\r\n\r\n'
>
> >>> and this is the raw data being signed:
>
> >>> GET&https%3A%2F%2Fapi.twitter.com%2F1%2Faccount
> >>> %2Fverify_credentials.json&oauth_consumer_key%3DGDdmIQH6jhtmLUypg82g
> >>> %26oauth_nonce%3D26979601%26oauth_signature_method%3DHMAC-
> >>> SHA1%26oauth_timestamp%3D1281612120%26oauth_token%3D819797-
> >>> Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw%26oauth_version%3D1.0
>
> >>> First thing I notice is that the ordering of the oauth_* items is all
> >>> over the place (i'll be sending a message to the python-oauth2 folks
> >>> once I figure out where they are hanging out) but even when I correct
> >>> for that and run it again, I *still* get an Invalid Signature error
> >>> from Twitter!
>
> >>> Here is the same debug run where all of the oauth_* items are sorted:
> >>> (debug output from urllib2, formatted so it's readable)
> >>> GET /1/account/verify_credentials.json?
> >>> oauth_consumer_key=GDdmIQH6jhtmLUypg82g&
> >>> oauth_nonce=21793837&
> >>> oauth_signature=5AQnyr09ZBcRz95SDPFOKizBEoo%3D&
> >>> oauth_signature_method=HMAC-SHA1&
> >>> oauth_timestamp=1281612568&
> >>> oauth_token=819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw&
> >>> oauth_version=1.0
> >>> HTTP/1.1\r\n
> >>> Accept-Encoding: identity\r\n
> >>> Host: api.twitter.com\r\n
> >>> Connection: close\r\n
> >>> Authorization: OAuth oauth_consumer_key="GDdmIQH6jhtmLUypg82g",
> >>> oauth_nonce="21793837", oauth_signature="5AQnyr09ZBcRz95SDPFOKizBEoo
> >>> %3D", oauth_signature_method="HMAC-SHA1",
> >>> oauth_timestamp="1281612568", oauth_token="819797-
> >>> Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw", oauth_version="1.0"\r\n\r
> >>> \n'
>
> >>> raw data being signed:
>
> >>> GET&https%3A%2F%2Fapi.twitter.com%2F1%2Faccount
> >>> %2Fverify_credentials.json&oauth_consumer_key%3DGDdmIQH6jhtmLUypg82g
> >>> %26oauth_nonce%3D21793837%26oauth_signature_method%3DHMAC-
> >>> SHA1%26oauth_timestamp%3D1281612568%26oauth_token%3D819797-
> >>> Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw%26oauth_version%3D1.0
>
> >>> looking for any clue-sticks, lifelines or hell, even a RTFM with a url
> >>> - thanks!
>
> >> Hi,
>
> >> Multiple things.
> >> * You don't have to send the oauth_* parameters in both the query and
> >> the Authorization: header.
>
> > The library i'm using does that - not sure why.  I'll explore removing
> > all but oauth_signature in a bit.
>
> Sorry if you misunderstood me. You should send all of them only once -
> either in the Authorization header or in the query.

Ah - I did completely get what you were saying wrong.  As soon as I
removed it from the header everything started to work!

amazing what happens when you pay attention ;)

>
> >> * The Base String seems fine, but you should not be using the keys on
> >> the wiki - they are random keys and will not work. (!)
>
> > I used the wiki keys only because another post ("oAuth and
> > AppleScript") someone requested that they use those keys so that the
> > signature value could be compared - I did the same.  I get Invalid
> > Signature when using keys that I've gotten back from Twitter
>
> That was me.
>
> Using this base string :
> GET&https%3A%2F%2Fapi.twitter.com%2F1%2Faccount%2Fverify_credentials.json&o 
> auth_consumer_key%3DGDdmIQH6jhtmLUypg82g%26oauth_nonce%3D26979601%26oauth_s 
> ignature_method%3DHMAC-SHA1%26oauth_timestamp%3D1281612120%26oauth_token%3D 
> 819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw%26oauth_version%3D1.0
>
> Key:
> MCD8BKwGdgPHvAuvgvz4EQpqDAtx89grbuNMRd7Eh98&J6zix3FfA9LofH0awS24M3HcBYXO5nI 
> 1iYe8EfBA
>
> Signature: e82GTcQn9Rjir1QMNw19/wTkAYA=
>
> So that part is fine as well.
>
> >> * The field order in the Authorization: header does not matter.
>
> > Is it the order in the URL and the Signature then that is the
> > "magic" ?
>
> Ordering the fields is only necessary for the Base String.
>

ok - learned something new - cool

>
>
> >> I don't know which secrets you are using so I can't verify your
> >> signature generation, although I assume that it is correct.
>
> > heck, i'm willing to post the key and secret so you can follow along -
> > it is tied to a test app so I can blow them away at anytime.
>
> >> Tom
>
> > thanks for the response
>
> Tom


Thanks so much for helping me get past a problem I was creating for
myself ;)

great work your doing!

Reply via email to