OAuth Server accept signature

[cynex]

Ive been trying to get this to work with WP-API on my Wordpress install, using the chome extension postman to test the oauth api. For some reason, the signatures do not match. I have used the appropriate consumer key / secret and generated the signature just fine on the postman client, but when i test that against the oauth response, they never match up. in the file "class-wp-json-authentication-oauth1.php" on line 560 :

$signature = base64_encode( hash_hmac( $hash_algorithm, $string_to_sign, $key, true ) );

    if ( $signature !== $consumer_signature ) {
        return new WP_Error( 'json_oauth1_signature_mismatch', __( 'OAuth signature does not match'), array( 'status' => 401 ) );
    }

I have echoed the $signature along with the error message, and then tested that signature using postman, and indeed it worked. So, can someone explain to me how we can get this to function correctly ? (postman is just my intermediary step -- Im actually indending to use guzzle + subscribe)

[archonia-chris]

I've been getting the same error. In my case the reason was that my Wordpress install is located in a subdirectory e.g. http://domain.com/sub1/sub2
The code that assigns $base_request_uri does not seem to take that into consideration.

This is the code:
$base_request_uri = rawurlencode( get_home_url( null, parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH ), 'http' ) );

Problem is

• $_SERVER['REQUEST_URI'] equals /sub1/sub2/...
• parse_url gives /sub1/sub2/... (not sure why this is done)
• get_home_url does http://domain.com/sub1/sub2 + /sub1/sub2/... so this gives http://domain.com/sub1/sub2/sub1/sub2/... !!!
  This is not the correct URL for hashing.

I changed it to
$base_request_uri = rawurlencode( get_home_url(NULL, str_replace(parse_url(get_home_url(), PHP_URL_PATH), '', parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH )), 'http' ) );
for lack of a better idea (I'm not familiar with Wordpress internals).

[cynex]

Our was having that issue as well, but I manually tried fixing it with a simple str_replace and still, no go. I verified the output was the same but for some reason still the signature wont return a valid comparison.

[archonia-chris]

I suggest you print out all the variables that are used to generate the signature and check if they contain appropriate values. That's how I found out the $base_request_uri was off.

[romuloctba]

Just add a space in the parameter oauth_token. the output (url encoded) must be: oauth_token%3D%2520%26oauth_version%3D1.0

edit: I mean add a space like: oauth_token=_ being _ representing the space

[trevordevore]

I ran into some problems while testing as well and I think there are a couple of things wrong with the check_oauth_signature function. Like @archonia I had the same problem with my blog having a path component. I changed the code to the following (my PHP is quite rusty):

// Fix: this failed if the WP blog roots to a folder on a domain
$home_url_path = parse_url(get_home_url (null,'','http'), PHP_URL_PATH );
$request_uri_path = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
// Strip away the beginning of the request URI path if the request URI path
// begins with the path component of the home URL
if (substr($request_uri_path, 0, strlen($home_url_path)) == $home_url_path) {
    $request_uri_path = substr($request_uri_path, strlen($home_url_path));
}
$base_request_uri = rawurlencode( get_home_url( null, $request_uri_path, 'http' ) );

In addition I'm not sure that the $query_string variable is being built correctly. The spec (http://tools.ietf.org/html/rfc5849#section-3.4.1.1) says the following with regards to concatenating the request parameters:

The request parameters as normalized in Section 3.4.1.3.2, after being encoded (Section 3.6).

The current code performs part of the normalization in that it rawurlencodes the keys/values of the $params array. The issue is that the code then combines the key/values using URLencoded representations of "&" and "=". I don't think that is correct. The key/value pairs need to be joined using "&" and "=" then the resulting string is rawurlencoded (http://tools.ietf.org/html/rfc5849#section-3.4.1.3.2). Here is what the updated code might look like:

foreach ( $params as $param_key => $param_value ) {
    $query_params[] = $param_key . '=' . $param_value; // join with equals sign
}
$query_string = implode( '&', $query_params ); // join with ampersand
$query_string = rawurlencode($query_string);

If the two changes mentioned above (or variants of them) are made then the OAuth authorization will work. At least it will for web applications. I'm starting another thread about the callback URL and desktop clients.

[trevordevore]

Regarding my comment about the $query_string variable. I was using code form a fork that provides a UI for generating consumer key/secret which didn't have the latest changes. I see that modifications have been made and create_signature_string seems to do the right thing (at least it works my existing code OAuth code in my desktop software).

I've submitted a pull request for the issue with authorization not working for blogs with a path component.

[romuloctba]

@trevordevore were you able to get it working?

[trevordevore]

@romuloctba Yes. I have forks on github of the WP-API and OAuth1 repositories combined with a 3rd party plugin for setting categories and tags. I'm pointing some of my customers towards using WP-API so I merged changes @modemlooper made into OAuth1 so that there is a UI for creating the key/secret.

I have submitted pull requests for all of the changes I made but for right now I am having my customers install my versions until the main branch is updated.

[romuloctba]

Yeah, I got your pull and works fine. I just noticed that postman app won't
create the right signature, but following RFC (or just using tools like
oauth.googlecode.com/svn/code/javascript/example/signature.html) generates
the correct one. Now it is working.

I wrapped the create key and secret code into a plugin so wp-cli is not
necessary. It works fine, but not yet relates to user accounts correctly

2014-10-01 9:42 GMT-03:00 Trevor DeVore notifications@github.com:

@romuloctba https://github.com/romuloctba Yes. I have forks on github
of the WP-API and OAuth1 repositories combined with a 3rd party plugin for
setting categories and tags. I'm pointing some of my customers towards
using WP-API so I merged changes @modemlooper
https://github.com/modemlooper made into OAuth1 so that there is a UI
for creating the key/secret.

I have submitted pull requests for all of the changes I made but for right
now I am having my customers install my versions until the main branch is
updated.

—
Reply to this email directly or view it on GitHub
#27 (comment).

[trevordevore]

Are you trying to get the key/secret to be different for each user? Right now it seems the key/secret is install specific. I think that is actually correct behavior.

Usually with OAuth a 3rd party application will register with the host service and get a key/secret. For example, I have a key/secret with Evernote and Dropbox. Since there is a central server the end user never needs to worry about this and I use the same key/secret regardless of which user is connecting.

Since WordPress is installed on different servers the key/secret has to be generated for each install. Each user then enters the key/secret in order to start the OAuth1 authentication process. They will still need to login with their username/password on the website in order to complete installation.

Or is there something else I am missing?

[romuloctba]

Yeah, but I don't think it concerns this thread thou....
I'm thinking of desktop and mobile apps (or other clients) creating a user
then generating specific key-secret for this user... When i got it working
i'll post here :D

2014-10-01 10:20 GMT-03:00 Trevor DeVore notifications@github.com:

Are you trying to get the key/secret to be different for each user? Right
now it seems the key/secret is install specific.

—
Reply to this email directly or view it on GitHub
#27 (comment).

[modemlooper]

You will need to create a frontend UI for a user to create the key CPT or write code that generates this for a user.

[bobbingwide]

See #32 for a simpler fix to the subdirectory install problem.