Taylor, I am presently using scribe java library for OAuth and as you said all spec compliant libraries the signature base string will only contain POST body parameter so does this one.
Also I will try to add the header 'Content-Type' to the library and let you know how it goes. Thanks, Rahul On Apr 29, 5:38 pm, Taylor Singletary <[email protected]> wrote: > Whether it matters before creating your signature or not depends entirely on > the OAuth library you are using. In spec-compliant OAuth libraries, the > signature base string will only contain POST body parameters when they are > of the application/x-www-form-urlencoded type -- most OAuth libraries need a > way to be instructed on the disposition of the content being passed as the > POST body and a common way is to look at an abstract request object of some > kind to determine the type of data being piped in rather than just trying to > guess or simply assuming that POST bodies will always be of the URL-encoded > type. There might be another way to instruct your library on the disposition > of data, but it's likely it'll just assume all POST data provided is of the > URL encoded variety. I don't think you have any issues with your code in > this area today. > > But as a best practice when dealing with an HTTP-based API of any kind, you > should be sending a Content-Type header whenever POSTing or PUTing any kind > of payload. You don't pass a Content-Type header on a GET because there is > no content being sent. > > It's likely that your OAuth library automatically sends the proper > Content-Type header on the OAuth negotiation steps because those steps are > required to use URL-encoded POST bodies by the spec. > > Taylor Singletary > Developer Advocate, Twitterhttp://twitter.com/episodOn Thu, Apr 29, 2010 at > 2:20 PM, Rahul <[email protected]> wrote: > > So what are trying to say is that i should explicitly add Content-type > > header in the message going out and that too before creating the > > signature? > > > Thanks, > > Rahul > > > On Apr 29, 4:58 pm, Taylor Singletary <[email protected]> > > wrote: > > > Since you're sending a status, you should be setting a Content-Type > > header > > > to indicate the type of payload -- it's best never to assume that a HTTP > > > server or a HTTP library will know how to understand a payload without > > being > > > explicitly told what kind of payload that is. The signature might be > > > mis-calculating on the Twitter side due to not including your parameters > > > when constructing it. > > > > Taylor Singletary > > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > On Thu, Apr 29, 2010 at 1:36 PM, Rahul <[email protected]> wrote: > > > > Hello, > > > > > To answer your questions. The following is the body response i receive > > > > back > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > > <hash> > > > > <request>/1/statuses/update.xml</request> > > > > <error>Incorrect signature</error> > > > > </hash> > > > > > Also, I am not setting any content type header at this point & I am > > > > using "POST" only for token negotiation. and have not tried any get > > > > restricted resource yet. I did try some but they seem to be public > > > > timeline etc which seems to be working good. > > > > > Any help on this is highly appreciated. > > > > > Thanks, > > > > Rahul > > > > > On Apr 29, 4:22 pm, Taylor Singletary <[email protected]> > > > > wrote: > > > > > Hi Rahul, > > > > > > I'm trying to think of other reasons. We might be throwing the > > invalid > > > > > signature error in a case where the signature is not in fact invalid. > > > > > > How about requests are not of the type POST? Have you had a GET > > (other > > > > than > > > > > OAuth token negotiation steps) work for you? When you were doing the > > > > token > > > > > negotiation steps, were you using POSTs or GETs? When performing a > > POST, > > > > are > > > > > you setting your HTTP Content-Type header to > > > > > "application/x-www-form-urlencoded"? > > > > > > What's the exact response from the server? There's usually a payload > > > > > included with the response that may give more clarity to the error. > > We > > > > have > > > > > some upcoming enhancements to the OAuth implementation that will > > return > > > > to > > > > > you the "signature base string we calculated" which would be useful > > here > > > > > now.. > > > > > > Taylor Singletary > > > > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > > > On Thu, Apr 29, 2010 at 1:12 PM, Rahul <[email protected]> > > wrote: > > > > > > Taylor, > > > > > > > A quick update on this. I tried generating the signature from my > > > > > > library and the page mentioned below they both seems tbe exactly > > the > > > > > > same..... > > >http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signin. > > > > .. > > > > > > > What else can be the reason and how come twitter is responding with > > > > > > Incorrect Signature ? > > > > > > > Thanks, > > > > > > Rahul > > > > > > > On Apr 29, 1:19 pm, Rahul <[email protected]> wrote: > > > > > > > Taylor, > > > > > > > > Thanks for taking a look at it. and to answer your question yes I > > do > > > > > > > pass the status in the signature basetring. > > > > > > > > Also below is my string which i pass to the below mentioned > > toSign > > > > > > > variable. > > > > > > > > toSign: > > > > > > > POST&https%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses > > > > > > > %2Fupdate.xml&oauth_consumer_key%xxxxxxxxxxxxxxx%26oauth_nonce > > > %3Df2756a360f610d375722ee97e4c2391f%26oauth_signature_method%3DHMAC- > > > > > > > SHA1%26oauth_timestamp%3D1272560943%26oauth_token%3D36554645- > > > > > > > xxxxxxxxxxxxxxxxxxx%26oauth_version%3D1.0%26status > > > > > > > %3Dhurrrrrrrrrrrrrray > > > > > > > > Mac mac = Mac.getInstance(HMAC_SHA1); > > > > > > > mac.init(key); > > > > > > > byte[] bytes = mac.doFinal(toSign.getBytes(UTF8)); > > > > > > > > and in the key i pass: consumerSecret + '&' + tokenSecret > > > > > > > > Thanks, > > > > > > > Rahul > > > > > > > > On Apr 29, 12:46 pm, Taylor Singletary < > > [email protected] > > > > > > > > wrote: > > > > > > > > > Hi Rahul, > > > > > > > > > When you are POSTing to statuses/update.xml -- are you > > including > > > > the > > > > > > status > > > > > > > > that you are posting in your signature base string? As a > > > > URL-encoded > > > > > > > > parameter, it should be included in both your POST body and the > > > > > > signature > > > > > > > > base string (but not in the HTTP authorization header). > > > > > > > > > Taylor Singletary > > > > > > > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > > > > > > On Thu, Apr 29, 2010 at 9:35 AM, Rahul <[email protected] > > > > > wrote: > > > > > > > > > Folks, > > > > > > > > > > I have been trying this and have already spent lot of time on > > > > this > > > > > > but > > > > > > > > > what i don't understand is how is getting the access token > > > > working > > > > > > and > > > > > > > > > post to update is not working when i am using the same > > signature > > > > > > > > > generation method for both the requests. > > > > > > > > > > Here is my complete scenario. > > > > > > > > > 1. fetch the request token > > > > > > > > > 2. redirect the user to the authurize page > > > > > > > > > 3. get the verifier from the new called back url > > > > > > > > > 4. getting the access token by passing oauth_token and > > > > auth_verifier > > > > > > > > > 5. create a new post request for update and sign the request > > with > > > > > > > > > HMAC.sign(toSign, consumerSecret + '&' + tokenSecret) > > > > > > > > > Note: toSign is the request with the following headers : > > > > > > > > > oauth_timestamp, oauth_signature_method, oauth_version, > > > > oauth_nonce, > > > > > > > > > oauth_consumer_key > > > > > > > > > 6. Send the request. > > > > > > > > > > Also if helpfull, i am using following values > > > > > > > > > oauth_nonce=MD5.hexHash(getTimestampInSeconds()) > > > > > > > > > oauth_signature_method=HMAC-SHA1 > > > > > > > > > oauth_version=1.0 > > > > > > > > > > I have verified most of the things and looks good to me, also > > > > there > > > > > > is > > > > > > > > > very less possibility of generating wrong signature as I have > > > > used > > > > > > the > > > > > > > > > same signature to get the access token and was able to > > > > successfully > > > > > > > > > receive it. > > > > > > > > > > Any pointers highly appreciated. > > > > > > > > > > Thanks, > > > > > > > > > Rahul > >
