Taylor, I am having a very similar problem. I think I am missing some
crucial point about the encoding method that needs to be used with
twitter. THe library I am working on has successfully authenticated
using Oauth with twitter. I have my access_token and
access_token_secret and I want to update my twitter status. If I only
send one word as my status, the update works. If I send two words
separated by a space the update does not work. I get back a 401
unauthorized response to the udpate request. My signing base string
POST request and response are below. As noted I have already
negotiated and OAuth access token so I don't show that information.

I noticed one thing in your example that is different from my code. In
my signing base string a space is encoded as %20. In yours, a space is
encoded as %2520. Do you have any ideas what the difference is between
your encoding method and mine?


Here is my signature base string:
POST&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses
%2Fupdate.xml&oauth_consumer_key%3Dbt7VUyYJ4adSHxIrGJYFxQ%26oauth_nonce
%3DISJERMBJCAQEYGUAWXAKQXTFPGFATRFUOQORGAMD%26oauth_signature_method
%3DHMAC-SHA1%26oauth_timestamp%3D1274372472%26oauth_token
%3D136131415-1kvYKiXUP8kS7yq39cGqmruDzvsF7uOoLPSK7Eh1%26oauth_version
%3D1.0%26status%3Dtest%20this


And the POST request I made follows below:

POST http://api.twitter.com/1/statuses/update.xml HTTP/1.1
Authorization: OAuth oauth_consumer_key="bt7VUyYJ4adSHxIrGJYFxQ",
oauth_nonce="ISJERMBJCAQEYGUAWXAKQXTFPGFATRFUOQORGAMD",
oauth_signature_method="HMAC-SHA1", oauth_timestamp="1274372472",
oauth_token="136131415-1kvYKiXUP8kS7yq39cGqmruDzvsF7uOoLPSK7Eh1",
oauth_version="1.0", oauth_signature="mkF7LWE4UqscMsjUlLQTRJFDFhg%3D"
Content-Type: application/x-www-form-urlencoded
Host: api.twitter.com
Content-Length: 18
Expect: 100-continue

status=test%20this


And the POST response
HTTP/1.1 401 Unauthorized
Connection: Keep-Alive
Connection: Proxy-Support
Content-Length: 135
Via: 1.1 RED-PRXY-21
Expires: Thu, 20 May 2010 16:51:16 GMT
Date: Thu, 20 May 2010 16:21:16 GMT
Content-Type: application/xml; charset=utf-8
Server: hi
Proxy-Support: Session-Based-Authentication
Status: 401 Unauthorized
WWW-Authenticate: Basic realm="Twitter API"
Cache-Control: no-cache, max-age=1800
Set-Cookie: k=131.107.0.71.1274372476598501; path=/; expires=Thu, 27-
May-10 16:21:16 GMT; domain=.twitter.com
Set-Cookie: guest_id=127437247670844927; path=/; expires=Sat, 19 Jun
2010 16:21:16 GMT
Set-Cookie:
_twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCDLPhLYoAToHaWQiJTE1M2MzMzg5ODc4MzI4%250ANDlkMWMwYjFlMzZkMTlkYTdkIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy
%250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--
c409bb092a71a15b4823075255ee464267520fba; domain=.twitter.com; path=/
Vary: Accept-Encoding

<?xml version="1.0" encoding="UTF-8"?>
<hash>
  <request>/1/statuses/update.xml</request>
  <error>Incorrect signature</error>
</hash>


On May 20, 6:45 am, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:
> Hi Onn,
>
> It's best to consider all space characters as %20 when building both your
> POST body and signature base string -- instead of using " " or "+", just get
> right down to it as "%20".
>
> I'll show you how a pretty varied string of characters would be correctly
> encoded both for the POST body and signature base string:
>
> Given that you want to set a status that says: "I can tweet many kinds of
> characters ! (* $ @ 漢字 عربي)"
>
> Your POST body should have that string encoded as:
>
> status=I%20can%20tweet%20many%20kinds%20of%20characters%20%21%20%28%2A%20%2­4%20%40%20%E6%BC%A2%E5%AD%97%20%D8%B9%D8%B1%D8%A8%D9%8A%29
>
> Which when passed into your Signature Base String will get URL escaped
> again:
>
> POST&http%3A%2F%2Fapi.twitter.com
> %2F1%2Fstatuses%2Fupdate.xml&oauth_consumer_key%3Dri8JxYK2ddwSV5xIUfNNvQ%26­oauth_nonce%3DFt6p0YgKlI2Htdk3WLE4mthwQXVpWc9Nv9ApzoQKUg%26oauth_signature_­method%3DHMAC-SHA1%26oauth_timestamp%3D1274362505%26oauth_token%3D119476949­-gF0B5O1Wwa2UqqIwopAhQtQVTzmfSIOSiHQS7Vf8%26oauth_version%3D1.0%26status%3D­I%2520can%2520tweet%2520many%2520kinds%2520of%2520characters%2520%2521%2520­%2528%252A%2520%2524%2520%2540%2520%25E6%25BC%25A2%25E5%25AD%2597%2520%25D8­%25B9%25D8%25B1%25D8%25A8%25D9%258A%2529
>
> The Content-Length for that fully-encoded POST body will be: 69
>
> And when Twitter spits the status back at you, in my case in XML:
> <?xml version="1.0" encoding="UTF-8"?>
> <status>
>   <created_at>Thu May 20 13:35:04 +0000 2010</created_at>
>   <id>14361447181</id>
>   <text>I can tweet many kinds of characters ! (* $ @ &#28450;&#23383;
> &#1593;&#1585;&#1576;&#1610;)</text>
>   <source>&lt;a href=&quot;http://realitytechnicians.com";
> rel=&quot;nofollow&quot;&gt;Crying Indian&lt;/a&gt;</source>
>   <truncated>false</truncated>
>   <in_reply_to_status_id></in_reply_to_status_id>
>   <in_reply_to_user_id></in_reply_to_user_id>
>   <favorited>false</favorited>
>   <in_reply_to_screen_name></in_reply_to_screen_name>
>   <user>
>     <id>119476949</id>
>     <name>OAuth Dancer</name>
>     <screen_name>oauth_dancer</screen_name>
>     <location>San Francisco, CA</location>
>     <description></description>
>     
> <profile_image_url>http://a3.twimg.com/profile_images/730275945/oauth-dancer_normal.jpg
> </profile_image_url>
>     <url>http://bit.ly/oauth-dancer</url>
>     <protected>false</protected>
>     <followers_count>11</followers_count>
>     <profile_background_color>C0DEED</profile_background_color>
>     <profile_text_color>333333</profile_text_color>
>     <profile_link_color>0084B4</profile_link_color>
>     <profile_sidebar_fill_color>DDEEF6</profile_sidebar_fill_color>
>     <profile_sidebar_border_color>C0DEED</profile_sidebar_border_color>
>     <friends_count>11</friends_count>
>     <created_at>Wed Mar 03 19:37:35 +0000 2010</created_at>
>     <favourites_count>0</favourites_count>
>     <utc_offset></utc_offset>
>     <time_zone></time_zone>
>     
> <profile_background_image_url>http://a3.twimg.com/profile_background_images/80151733/oauth-dance.png
> </profile_background_image_url>
>     <profile_background_tile>true</profile_background_tile>
>     <notifications>false</notifications>
>     <geo_enabled>false</geo_enabled>
>     <verified>false</verified>
>     <following>false</following>
>     <statuses_count>31</statuses_count>
>     <lang>en</lang>
>     <contributors_enabled>false</contributors_enabled>
>   </user>
>   <geo/>
>   <coordinates/>
>   <place/>
>   <contributors/>
> </status>
>
> Hope this helps.
>
> TaylorOn Thu, May 20, 2010 at 5:03 AM, Onn E <onn.elbo...@gmail.com> wrote:
> > 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%250AaW9uQ­29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA
> > %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,"trunca­ted":false,"in_reply_to_status_id":null,"coordinates":null,"user":
> > {"favourites_count":
>
> > 2,"description":"*********","contributors_enabled":false,"lang":"en","profi­le_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":"87bc­44","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 »

Reply via email to