-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Signature and Callback (Issues WP-API/OAuth1#59, WP-API/OAuth1#64, WP-API/OAuth1#91) #92
base: master
Are you sure you want to change the base?
Conversation
This function was actually decoding parameters that shouldn't have been decoded, then re-encoding them. See: #91 The idea behind removing this function is that parameters should be encoded as needed, not through a brute-force function like this, which can cause unintended side-effects for parameters which contain portions that are already encoded.
Hi, thanks for the PR! Usually I'd close out combined PRs, but it seems like this relies on the others? Can you give an example of requests that don't work beforehand, and do work after? |
Hi, I originally had mirrored the other two commits myself, but I brought in the commits from @sblaz and @AlexC to give credit where it was due. I just made them work together. What this fixes is any time you have an oauth_callback parameter that is already URL encoded twice. For me, I'm integrating hello.js with this, and it sends an encoded URL with an encoded parameter in the query string. Here's the progression (hand-writing URLs here, but I hope you get the idea)
This is the problem. Because when the signature is generated off of this string, it doesn't match the one that was calculated by my server, because the oauth_callback parameter was modified via normalize_parameters and is now incorrect. Also, even if you get past the signature, you can't call a URL like this: http://myserver/oauth-proxy?state={ id: '123', status: 'authorizing' } I think this only comes up if the oauth_callback URL has an encoded parameter, so if others sent a callback URL without any encoded parameters, they would not run afoul of this particular issue. |
These should all be fixed in #98 now, I think. Can you give it a try and confirm please? :) |
I just tried this out, and I'm afraid it hasn't helped fix the problem. Here's the code in question, and it appears to be still intact: OAuth1/lib/class-wp-rest-oauth1.php Line 733 in 141f4f8
protected function normalize_parameters( &$key, &$value ) {
$key = rawurlencode( rawurldecode( $key ) );
$value = rawurlencode( rawurldecode( $value ) );
} This code is what is decoding and then re-encoding, which makes the signatures not match and the URL unusable (see example comment above). I'll post a comment below this one with cut-and-pastes of the strings that are being signed on both ends. |
From my Client:
From the Server (OAuth1 plugin):
|
@rmccue It's been a while since we last had activity here. Is this still something you'd like to address? |
I'm interested in this discussion as well. |
This Pull Request integrates commits from 2 other Pull Requests.
This Pull Request accomplishes:
This Pull Request fixes the issues:
AlexC's commit: Ensure OAuth1 signature is created as per the spec
This commit fixes signature generation for certain cases, however it adds an extra encoding in addition to normalize_parameters which can cause an issue (addressed below.)
coderkevin's commit: Remove normalize_parameters function
This commit fixes #91 and relies on AlexC's commit above to encode inside of join_with_equals_sign() to encode parameters as the param string is generated.
sblaz's commit: Fix issue WP-API/OAuth#59, OAuth callback isn't called
This commit stores and carries over the oauth_callback parameter for post-authentication. It relies on the above two commits to ensure the callback parameter remains correctly encoded.