Hi Taylor, Thanks for the pointers! Turned out the problem was related to encoding. I fixed the encoding on the status in the body, and then noticed that I wasn't encoding the '=' at the end of the signature in the header. When I'd put the signature in the body, it was encoded with all the other parameters, so worked correctly. Now both ways are fine.
Thanks again, ben On Aug 5, 3:21 pm, Taylor Singletary <taylorsinglet...@twitter.com> wrote: > Hi Everyone on this thread, > > A few clarifications: > > - The "realm" isn't required, but we'll take a realm if you provide one. > Really, it's a no-op in our system. We don't care if you have it or not, and > if you provide it, we don't do anything with it. > > - Timestamp is important in that the oauth_timestamp in your requests should > be within about 5 minutes of our servers. We return the current time in a > header within each response, failed or otherwise. One quick way to get a > non-rate-limited check on the current time according to twitter is to send a > HEAD request to /1/help/test.xml and inspect the "Date" header, > recontextualizing your app's concept of the current time based on that. > > Back to the original poster's issue, I noticed you're essentially trying to > post this status: > > "Test 1 2 3 4 1280937572396" > > But your POST body shows this status over-encoded: > "status=Test%25201%25202%25203%25204%25201280937572396" > > When it should be: > "status=Test%201%202%203%204%201280937572396" > > The encoding in your POST body is correct as to what should be in your > signature base string. This might be what is causing your invalid signature > errors. > > Taylor > On Thu, Aug 5, 2010 at 5:10 AM, Ben Jones > <benjamin.david.jo...@gmail.com>wrote: > > > Hi Tom/Jacky, > > > Thanks for responding! > > > Apologies if this is a double post, last one didn't seem to go > > through. > > > I tried removing 'realm' from the Authorization header, and this > > changed the > > response the first time, to something like 'Couldn't authenticate you > > using > > OAuth', but then returned to the previous behaviour of throwing 500 > > errors. > > > What should I look out for with regards timestamps? I'm following the > > advice > > from the OAuth spec, in that they have to be in seconds, and equal or > > greater than the last used. Do they have to sync with Twitter's clock? > > > Thanks again! > > ben > > > On Aug 5, 12:37 am, Tom <allerleiga...@gmail.com> wrote: > > > Oops, silly me, didn't read the full post. Sorry. > > > > Make sure to watch for character encoding and timestamps. Especially > > > timestamps are known to cause trouble. > > > > 401 errors are almost never an issue at Twitter. > > > > Tom > > > > On Aug 5, 1:34 am, Tom <allerleiga...@gmail.com> wrote: > > > > > You are sending realm="" in your Authorization header. It doesn't > > > > belong there. ;-) > > > > > Tom > > > > > On Aug 4, 6:19 pm, Ben Jones <benjamin.david.jo...@gmail.com> wrote: > > > > > > Hi all, > > > > > > I'm currently writing my own OAuth lib for use with Twitter and have > > > > > gotten stuck whilst using the > > > > > Authorization HTTP header, rather than putting the OAuth parameters > > in > > > > > the body. > > > > > > An example of a request that is failing is: > > > > > > POST /1/statuses/update.xml HTTP/1.1 > > > > > Authorization: OAuth realm="http://api.twitter.com/1/statuses/ > > > > > update.xml", > > > > > oauth_consumer_key="xxxxxxxxxxxxxxxxx", > > > > > oauth_token="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx", > > > > > oauth_nonce="xxxxxxxxxxxxxxxxxxxxx", > > > > > oauth_timestamp="1280937572", > > > > > oauth_signature_method="HMAC-SHA1", > > > > > oauth_version="1.0", > > > > > oauth_signature="DLPyc3h6BcC5zbGXrUcujvZnqxk=" > > > > > User-Agent: Java/1.6.0_07 > > > > > Host: api.twitter.com > > > > > Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 > > > > > Connection: keep-alive > > > > > Content-type: application/x-www-form-urlencoded > > > > > Content-Length: 53 > > > > > > status=Test%25201%25202%25203%25204%25201280937572396 > > > > > > ...(token etc blanked out, and new lines added in) > > > > > > This results in the server returning a 500 error and the "Something > > is > > > > > technically wrong." error page. > > > > > I've talked to another developer who doesn't experience this. I've > > > > > tried this with the parameters > > > > > alphabetically ordered, unordered and with and without the 'realm' > > > > > parameter, which isn't used in thehttp:// > > dev.twitter.com/pages/authpage. > > > > > > I don't have the same problem (as in the 500 error) when I put the > > > > > OAuth parameters in the request > > > > > body, but this often fails as well with 401 'Invalid signature' > > > > > errors. What's strange is that putting the > > > > > OAuth parameters into the form at Hueniverse's OAuth request signing > > > > > page (http://tinyurl.com/y9bvjyt) > > > > > shows them, including the signature, to be correct. If I retry the > > > > > same request, it eventually works > > > > > (sometimes it works the first time, just not consistently), so I > > don't > > > > > think I'm calculating the signature > > > > > incorrectly. > > > > > > Are the 401 errors occurring because Twitter is busy, or am I doing > > > > > something wrong? > > > > > > Thanks in advance, any help would be greatly appreciated! > > > > > ben
