OAuth Server accept signature about oauth1 HOT 15 CLOSED

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).

from oauth1.

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.

from oauth1.

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.

from oauth1.

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

from oauth1.

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.

from oauth1.

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.

from oauth1.

@trevordevore were you able to get it working?

from oauth1.

@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.

from oauth1.

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 [email protected]:

@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).

from oauth1.

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?

from oauth1.

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 [email protected]:

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).

from oauth1.

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.

from oauth1.

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

from oauth1.

Make sure that your signing correctly, especially if using POSTMAN:
http://oauth1.wp-api.org/docs/basics/Signing.html

If you're using POSTMAN you can set it to OAuth 1.0 under Authorization and then select the options below (don't enable "add params to header")

• Add empty params to signature
• Encode OAuth signature
• Save helper data to request

Mine did not work until I specifically enabled those options, as enabling add params to header will actually change the signature ;-)

from oauth1.

Closing this out now, all looks ok here.

from oauth1.