Long POST vars included in Authorization HTTP header cause error

Hi,

I'm using the oauth_client_class in an application for Tumblr (called Tumblr Crosspostr) but I'm seeing a problem wherein it seems that overly long 'Authorization' header values cause Tumblr to return a "400 Bad Request" reply.

I'm not knowledgeable enough about OAuth to understand the specifics of this implementation, so my question has to do with whether the behavior I'm seeing is appropriate and expected.

Specifically, I have initialized this class with the $server variable set to 'Tumblr' and then I build an array to POST that includes a lot of text data. When I turn $debug on, I see an HTTP dialogue in my logs that include every single variable added to the POST data array in the "Authorization" HTTP header in addition to being present in the body of the POST'ed request, not just the various oauth protocol variables (like "oauth_signature"). For instance:

POST /v2/blog/tumblr.petermolnar.eu/post/edit HTTP/1.1
Host: api.tumblr.com
User-Agent: PHP-OAuth-API (http://www.phpclasses.org/oauth-api $Revision: 1.83 $)
Accept: */*
Authorization: OAuth oauth_consumer_key="[REDACTED]",oauth_nonce="[REDACTED]",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1396906369",oauth_version="1.0",oauth_token="SsmEfOJVW2Gpm8RsP5GYVdOm3c03sKjfx1TaODBIUuPLufb8Vs",type="text",state="published",tags="%2C",date="2014-04-07%2013%3A22%3A01%20GMT",format="html",slug="echoes-in-the-dark",source_url="https%3A%2F%2Fpetermolnar.eu%2Fblips%2Fechoes-in-the-dark%2F",title="echoes%20in%20the%20dark",[…SNIPPED FOR LENGTH…]tweet="off",id="81997533822",oauth_signature="4tUtmhs4wdqFkrAJ7Pu3%2F7hbdxA%3D

Note that in addition to the oauth* variables, my application-specific variables are also included in this header.

My questions are:

1) Can an Authorization header that's too long result in the kind of 400 Bad Request errors I'm seeing from OAuth 1.0a servers like api.Tumblr.com?
2) Using Tumblr (or any OAuth 1.0a server), is it correct to send all of the POST variables in the Authorization header or is it correct to only send the oauth-specific variables?
3) If the answer to question 2 is that it's incorrect to send application-specific variables in the Authorization header, how do I prevent the library from doing that?

Thanks for your time and attention.

OAuth 1.0a requires that request parameters also make part of the signature because that is the way to prevent tampering requests. Somebody could look at the requests and send them again altering the parameters if they were not signed.

The actual request error may or may not be related with your parameters. It would be interesting to see if the response also returned some other error messages that explain the error.

Can you show the code you are using to call the CallAPI function so I can see if I can reproduce the problem?

Thanks for your reply, Manuel.

Consider also looking at this thread on the project support forum:

wordpress.org/support/topic/error-4 ...

In particular, note that the PEAR OAuth client does not behave in the same way as oauth_client_class in that it does not send the POST parameters in the Authorization header and so Tumblr does not issue a Bad Request error.

The call to your CallAPI library function can be seen here:

plugins.trac.wordpress.org/browser/ ...

That function is called from my own intermediary class from a generic method called "talkToService", visible here:

plugins.trac.wordpress.org/browser/ ...

and the actual WordPress plugin code calls the specific function for Tumblr (different functions to create a new post, edit an existing one, etc.) from here:

plugins.trac.wordpress.org/browser/ ...

The reason for this architecture is that I am using oauth_client_class as the OAuth component in numerous more generic plugins that all require OAuth support, hence my use of extended abstract classes.

In any event, it seems that when I replace oauth_client_class with PEAR's OAuth, Tumblr no longer complains with Bad Request errors.

Thanks for your time looking into this with me. I appreciate it!

I tried it here but I could not reproduce the problem.

I suspect that your problem is that you are not passing the correct parameters that Tumblr API expects. That is why I think it would be useful if you enabled error logging and show the actual error response that Tumblr is returning.

Below follows a sample call that shows how I am calling it.

Also make sure you are using the latest version of the OAuth client API to make sure you are not using a version with past bugs.

$parameters = array(
'id'=>'82171796530',
'title'=>'Hello',
'body'=>'World'
);

$success = $client->CallAPI(
'http://api.tumblr.com/v2/blog/mallemos/post/edit',
'POST', $parameters, array('FailOnAccessError'=>true), $edit);

Manuel,

The problem did not occur for you because the length of your HTTP request is so short. As described in my first post here as well as the detailed email thread to which I linked on the WordPress support forum, the issue only occurs when there are very long POST values.

I can guarantee that the issue is not caused by unexpected API parameters.

A full log of the HTTP dialogue showing both successes and failures, which was also linked in the WordPress support forum, is here:

Success with a short post:
petermolnar.eu/tmp/tumblr-crosspost ...

Failure with a longer post, same POST parameters:
petermolnar.eu/tmp/tumblr-crosspost ...

Please consider reading both my description of the problem and the links I provided to you a little more closely?

Also, for comparison, here is the log of an HTTP dialogue using PEAR's OAuth package on the same data:

pastebin.com/Enfs8DnA

Notice how PEAR's OAuth package does not copy all of the HTTP request body's POST vars into the Authorization header, and so Tumblr does not issue a 400 Bad Request when that header's value is too large.

Given these logs, it seems that at least Tumblr does not require each and every POST variable to be copied from the HTTP request body to the Authorization header, because all it needs is a valid oauth_signature *of* the request body in the Authorization header.

Is there a way to configure oauth_client_class to ensure it will not copy POST vars into the HTTP Authorization header?

Thanks again for your attention to this.

OK, I got the problems, POST parameters must be signed too but not included in the header.

I will submit a fixed version soon once I confirm it does not break other APIs.

Hi, I see your newest update to oauth_client.php published on 2014-04-11 03:27 addresses the long POST vars in the Authorization header. Thanks for that.

Unfortunately, I just tried to replace my project's copy of oauth_client.php with the latest one you released and another problem has appeared. Without making any changes to ANY of my code, the debug output now produces the following error:

OAuth client: Error: is not a supported version of the OAuth protocol

Again, I stress that I have made no changes to my code other than replacing the oauth_client.php file with the new version you provided. Here is how I am calling the library:

$client->server = 'Tumblr';
$client->client_id = $consumer_key;
$client->client_secret = $consumer_secret;
$client->Initialize();

Later, when I try to do Process(), the function returns (bool)false and my logs show the Error output shown above.

Thanks again for your attention in helping me resolve this issue.

Ah, I figured out the problem: you removed Tumblr from the built-ins and added it to an external configuration file, so I need to configure $client like this, now:

$client->server = 'Tumblr';
$client->client_id = $consumer_key;
$client->client_secret = $consumer_secret;
$client->configuration_file = dirname(__FILE__) . '/oauth_api/oauth_configuration.json';
$client->Initialize();

Thank you again for addressing this issue quickly.