Fixing Error Code 32 when Using the Twitter API

Yesterday, I started working with the twitter API. It’s been a long time since I did anything with it, and now that it uses Oauth, I found that it is a bit less intuitive, but after a couple of times you get used to validating requests, and to the tedious signing process. However, I noticed that some of my requests were failing with an error code of 32. This is the actual message I got as response:

{“errors”:[{“message”:”Could not authenticate you”,”code”:32}]}

This message is really useless considering there are many reasons why your authentication could be failing. By looking at that error message all you know is that you could not be authenticated, but you don’t know why. The reasons, as it turns out, are not as intuitive as you may think.

When someone tells you that you could not be authenticated, your first thought is to consider whether you have the right credentials. But once you’ve verified that you do, what other options do you have? Well, it could be that the signature is incorrect because you did not order the parameters in the right order. It could also be that your server is using a different timezone. Who would ever think of these as reasons for failing authentication? That is where the message becomes useless.

However, these two instances are pretty much the main reason for failed authentications, so a search will most likely give you a variation of any of these two possible reasons. However, what do you do after you are certain that none of them are the reason? You are pretty much out of luck.

One of the first things I do if something is not going according to plan, is to check that the signature being generated is the same one that twitter generates when using their Oauth Tool. For this you need to know how to modify the timestamp, and the nonce in whatever framework you are using. In mi case, I’m just doing everything by hand, so editing those values is a matter of editing a couple variables. If the signature, the Authorization string, and the signature string coincide with the ones generated by twitter, there should be no reason why your request should fail. However, despite of all 3 matching, my requests were being failed over and over.

The first thing that I noticed that made little sense was that some request were successful, while other were not. This made no sense. Why would twitter fail to authenticate one request, but not another one when both use the same credentials. This is yet another instance of that message being totally useless.

I decided to go over my requests and find out what was different. I noticed that the request that failed were the ones where data was being posted. I was using php’s curl to do the requests, so I decided to go and take a look at the documentation just to make sure I was doing everything right.

I discovered that PHP can take POST parameter in two ways when using curl. The first one is a string of key value pairs separated by ampersands:


key1=val1&key2=val2

The second one is using an array:


array (
  'key1' => 'val1',
  'key2' => 'val2'
);

Well, it turns out that if you use an array, php will set the Content-Type header to multipart/form-data, but then twitter will fail to authenticate you. Although the reason for failing the request may be an acceptable one, the message you get back is not, because it gives you no indication whatsoever as to why the request failed.

Next time you encounter that error code 32, remember to check you headers as well as your data, along with the server timezone, the order of your parameters when building the signature string, and you may as well check that you are not wearing anti-twitter outfit, just to be sure twitter will not deny your request because of that too.