Hi Taylor,
I am using Curl to update status.
I use POST method.
The new status is not included in the headers, but is included in the
POST body and in the signature base string.
Also (and this Curl does automatically for me) I am sending the
following header:
Content-Type: application/x-www-form-urlencoded.
My new status value is URL encoded (UTF-8).
And now to the business itself:
I know my signature method is correct since I am able to update single
word statuses with no special characters, such as: "hello", "ok",
"magnificent" and such. They work just fine.
But when trying to update statuses with characters such as: " ", "!",
"@". It will throw me with a 401:
{"request":"/1/statuses/update.json","error":"Incorrect
signature"}
I'm attaching here the curl verbose:
"
curl -v -X POST -H 'Authorization: OAuth
oauth_nonce="5671352764895675466", oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1274355202", oauth_consumer="**********************",
oauth_signature="**************************************",
oauth_version="1.0",
oauth_token="**************************************"' -d
"status=magnificent" https://api.twitter.com/1/statuses/update.json
* About to connect() to api.twitter.com port 443 (#0)
* Trying 128.242.240.61... connected
* Connected to api.twitter.com (128.242.240.61) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; O=*.twitter.com; OU=GT57932074; OU=See
www.rapidssl.com/resources/cps (c)09; OU=Domain Control Validated -
RapidSSL(R); CN=*.twitter.com
* start date: 2009-05-26 12:14:57 GMT
* expire date: 2010-07-27 06:10:16 GMT
* common name: *.twitter.com (matched)
* issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global
eBusiness CA-1
* SSL certificate verify ok.
> POST /1/statuses/update.json HTTP/1.1
> User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k
> zlib/1.2.3.3 libidn/1.15
> Host: api.twitter.com
> Accept: */*
> Authorization: OAuth oauth_nonce="5671352764895675466",
> oauth_signature_method="HMAC-SHA1", oauth_timestamp="1274355202",
> oauth_consumer_key="**********************",
> oauth_signature="**************************************",
> oauth_version="1.0", oauth_token="**************************************"
> Content-Length: 18
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Date: Thu, 20 May 2010 11:27:15 GMT
< Server: hi
< Status: 200 OK
< X-Transaction: 1274354835-66746-24190
< ETag: "61a0fc27a676be7b50eb72042998d554"
< Last-Modified: Thu, 20 May 2010 11:27:15 GMT
< X-Runtime: 0.18394
< Content-Type: application/json; charset=utf-8
< Content-Length: 1212
< Pragma: no-cache
< X-Revision: DEV
< Expires: Tue, 31 Mar 1981 05:00:00 GMT
< Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0
< Set-Cookie: k=62.219.129.78.1274354835642625; path=/; expires=Thu,
27-May-10 11:27:15 GMT; domain=.twitter.com
< Set-Cookie: guest_id=127435483564553842; path=/; expires=Sat, 19 Jun
2010 11:27:15 GMT
< Set-Cookie: lang=en; path=/
< Set-Cookie:
_twitter_sess=BAh7CjoRdHJhbnNfcHJvbXB0MDoPY3JlYXRlZF9hdGwrCMegd7UoAToMY3Ny
%250AZl9pZCIlNTUxMThjYjg0ZTc2MTU2MzAwZWM1MjA1NGMxMmNlZGM6B2lkIiVm
%250AOTdiMWFlNTc4OGZhODM2NjRkZTRhMTdkMTgxOGFlMSIKZmxhc2hJQzonQWN0%250AaW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA
%253D%253D--0b5f5cee23124380fd2db90ff369fee30c0122d9;
domain=.twitter.com; path=/
< Vary: Accept-Encoding
< Connection: close
<
{"in_reply_to_user_id":null,"contributors":null,"source":"<a href=
\"http://www.snaptu.com\"; rel=\"nofollow\">Snaptu Mobile</
a>","created_at":"Thu May 20 11:27:15 +0000
2010","in_reply_to_screen_name":null,"place":null,"favorited":false,"truncated":false,"in_reply_to_status_id":null,"coordinates":null,"user":
{"favourites_count":
2,"description":"*********","contributors_enabled":false,"lang":"en","profile_link_color":"0000ff","profile_image_url":"http://
s.twimg.com/a/1274144130/images/
default_profile_2_normal.png","geo_enabled":false,"time_zone":"Greenland","profile_sidebar_fill_color":"e0ff92","screen_name":"SnaptuDummy","following":false,"verified":false,"created_at":"Sun
Mar 22 13:31:04 +0000 2009","profile_background_image_url":"http://
s.twimg.com/a/1274144130/images/themes/theme1/
bg.png","profile_background_tile":false,"followers_count":
24,"protected":false,"url":"http://
www.snaptu.com","name":"*********","friends_count":*,"profile_sidebar_border_color":"87bc44","profile_background_color*
Closing connection #0
* SSLv3, TLS alert, Client hello (1):
":"9ae4e8","location":"Israel","id":25817409,"statuses_count":
245,"notifications":false,"utc_offset":-10800,"profile_text_color":"000000"},"geo":null,"id":**********,"text":"magnificent"}
"
Thanks you all for the support.
Onn E
On May 17, 4:46 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:
> Hi Gero,
>
> This particular issue looked to have been caused by a quirk in the way that
> the Scribe library was encoding spaces. The library has since been updated
> by the author.
>
> However, if you're still having the issue in another implementation, I'll be
> happy to help. Can you share the POST body of the request and your signature
> base string of when you're having the issue?
>
> Taylor Singletary
> Developer Advocate, Twitterhttp://twitter.com/episod
>
>
>
> On Mon, May 17, 2010 at 12:12 AM, Gero <gero.verm...@gmail.com> wrote:
> > Hi,
>
> > Any updates on this issue? I'm running into the same problem and have
> > not yet been able to resolve it.
>
> > Regards,
> > Gero
>
> > On May 1, 12:42 am, Taylor Singletary <taylorsinglet...@twitter.com>
> > wrote:
> > > Hi Pablo,
>
> > > Thanks for chiming in about Scribe. I'll take a look again soon at Scribe
> > > and see if I can ascertain its potential fault (or our own if that is the
> > > case).
>
> > > Keep up the good work on your OAuth library, Pablo! :)
>
> > > Taylor Singletary
> > > Developer Advocate, Twitterhttp://twitter.com/episod
>
> > > On Fri, Apr 30, 2010 at 3:31 PM, Pablo Fernandez <
> > fernandezpabl...@gmail.com
>
> > > > wrote:
> > > > Hi Taylor!
>
> > > > I believe Rahul is having this problem while using my library (http://
> > > > github.com/fernandezpablo85/scribe)
>
> > > > I've tested myself, I'm pretty sure the error lies in my code but I
> > > > can't tell why :S
>
> > > > Here's the string that gets signed and the OAuth header in case that
> > > > helps!
>
> > > > String to sign >>
>
> > > > POST&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses
> > > > %2Fupdate.xml&oauth_consumer_key%3D6icbcAXyZx67r8uTAUM5Qw%26oauth_nonce
> > > > %3D32c0b090041a4b233a36590a10c8749e%26oauth_signature_method%3DHMAC-
> > > > SHA1%26oauth_timestamp%3D1272666648%26oauth_token%3D14654522-
> > > > ayJ064ck0Gtp1ABmjVVxMqd0OcgIG0fMRPFxN00E%26oauth_version%3D1.0%26status
> > > > %3DScribe%2520works.%2520Hell%2520yeah%2521
>
> > > > OAuth header >>
>
> > > > OAuth oauth_consumer_key="6icbcAXyZx67r8uTAUM5Qw",
> > > > oauth_nonce="32c0b090041a4b233a36590a10c8749e",
> > > > oauth_signature="hmzME2L2qAmzRYOj5P%2BBcja9ECg%3D",
> > > > oauth_signature_method="HMAC-SHA1", oauth_timestamp="1272666648",
> > > > oauth_token="14654522-ayJ064ck0Gtp1ABmjVVxMqd0OcgIG0fMRPFxN00E",
> > > > oauth_version="1.0"
>
> > > > Pablo
>
> > > > PS: Kudos for developer.twitter.com. the site rocks!
>
> > > > On Apr 30, 3:34 pm, Rahul <rahul.jun...@gmail.com> wrote:
> > > > > Taylor,
>
> > > > > Here you go. I have tried adding the content type as follows.
>
> > > > > conn.setRequestProperty("Content-Type", "application/x-www-form-
> > > > > urlencoded");
>
> > > > > But this doesn't help at all and i still continue receiving the same
> > > > > error of incorrect signature.
>
> > > > > Any guess?
>
> > > > > Thanks,Rahul
>
> > > > > On Apr 29, 9:03 pm,Rahul<rahul.jun...@gmail.com> wrote:
>
> > > > > > 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 <
> > taylorsinglet...@twitter.com>
> > > > > > 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/episodOnThu, 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:
> > > > > > > > > > > HiRahul,
>
> > > > > > > > > > > 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.
>
> ...
>
> read more »
