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, Twitter
http://twitter.com/episod


On Thu, Apr 29, 2010 at 2:20 PM, Rahul <rahul.jun...@gmail.com> 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 <taylorsinglet...@twitter.com>
> 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 <rahul.jun...@gmail.com> 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 <taylorsinglet...@twitter.com>
> > > 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 <rahul.jun...@gmail.com>
> 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 <rahul.jun...@gmail.com> 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 <
> taylorsinglet...@twitter.com
> >
> > > > > > 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 <rahul.jun...@gmail.com
> >
> > > 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
>

Reply via email to