php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #64967 OAuth::fetch() issue
Submitted: 2013-06-03 21:46 UTC Modified: 2013-06-04 18:59 UTC
From: gregs at net-virtual dot com Assigned:
Status: Not a bug Package: oauth (PECL)
PHP Version: 5.4.15 OS: Linux 2.6.18-194.3.1.el5 #1 SMP
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: gregs at net-virtual dot com
New email:
PHP Version: OS:

 

 [2013-06-03 21:46 UTC] gregs at net-virtual dot com 
Description:
------------
Seems like OAuth::fetch() sometimes fetches the wrong url.

All the uris below have a signature that will validate, but in Sig3 the URI being 
sent to the server is double-encoded.

Test script:
---------------
$consumer_key = 'consumer_key';
$consumer_secret = 'consumer_secret';
$token_key = 'token_key';
$token_secret = 'token_secret';
$timestamp = '1370292596';
$nonce = 'HvKwTK';

$method = 'GET';

$oauth = new OAuth($consumer_key, $consumer_secret, OAUTH_SIG_METHOD_HMACSHA1);
$oauth->enableDebug();
$oauth->setNonce($nonce);
$oauth->setTImestamp($timestamp);
$oauth->setToken($token_key, $token_secret);



$url1 = 'http://example.com/test';
$params1 = array('_test' => 'Test');
$sig1 = $oauth->generateSignature($method, $url1, $params1);
print "Sig1: $sig1\n";

$method = 'GET';
$url2 = 'http://example.com/test?_test=Test';
$params2 = array();
$sig2 = $oauth->generateSignature($method, $url2, $params2);
print "Sig2: $sig2\n";

$url3 = 'http://example.com/test';
$params3 = array('_test' => 'Test%3F_testbar%3D%26_testfoo%3D.ImageSizes%3F_testbar%3D%26_testfoo%3D');
$sig3 = $oauth->generateSignature($method, $url3, $params3);
print "Sig3: $sig3\n";

$url4 = 'http://example.com/test?_test=Test%3F_testbar%3D%46_testfoo%3D.ImageSizes%3F_testbar%3D%46_testfoo%3D';
$params4 = array();
$sig4 = $oauth->generateSignature($method, $url4, $params4);
print "Sig4: $sig4\n";


Expected result:
----------------
Sig1: XUJ58bhwrXHygghKp4z6gXLruoI=
Sig2: XUJ58bhwrXHygghKp4z6gXLruoI=
Sig3: emLq0laWZC8Uhj2ApNRM8B88K8s=
Sig4: emLq0laWZC8Uhj2ApNRM8B88K8s=


Actual result:
--------------
Sig1: XUJ58bhwrXHygghKp4z6gXLruoI=
Sig2: XUJ58bhwrXHygghKp4z6gXLruoI=
Sig3: JiCJ5a93kX/4/zpUH/wv8ZBGSo4=
Sig4: emLq0laWZC8Uhj2ApNRM8B88K8s=

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-04 11:34 UTC] jawed@php.net
-Status: Open +Status: Not a bug
 [2013-06-04 11:34 UTC] jawed@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

I believe this is expected behavior per spec. Can you please point out which 
provider is not handling this properly?
 [2013-06-04 18:31 UTC] gregs at net-virtual dot com 
It is a bug.  And its a pretty big one.  But there is no documentation about the 
second parameter (what I am calling $params), so I have no idea if that should 
be double-encoding the passing in array or not.  Regardless, it seems like a 
REALLY awful implementation if I am telling your class to fetch a url with a 
given set of parameters and thats not what you are sending to the server.

So, basically:

Sig1/Sig2: The signature is invalid for the url (go to 
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/ 
and punch in all the data provided you will see the signature is Sig2 for the 
uri of Sig1 - and arguably should be the same uri as Sig2 - but if Sig2 is going 
to insist on sending a different uri to the server then the signature is wrong).

The part you are getting wrong is:

1. You are manipulating the parameters that are sent to the server - encoding 
should only be being done to generate the signature.  There is no part of the 
OAuth spec that says this should be happening.  I don't really care about that 
though, there's a way to use your package which does not mangle the uris (Sig1 
instead of Sig2 - although Sig2 seems cleaner).

2. The part you seem to be getting wrong is 3.4.1.1 
(http://tools.ietf.org/html/rfc5849#section-3.4.1).  You *are* supposed to 
urlencode the encoded string before appending it to the string you are going to 
ultimately encode to generate the signature and it does not seem that you are.

Perhaps you should document that when passing parameters in as the second 
argument to generateSignature() and second to fetch() that your library is going 
to urlencode them.
 [2013-06-04 18:42 UTC] jawed@php.net 
It would be useful to document. However, I think it is intuitive that "resource 
parameters" are in fact URL encoded on the way out. In contrast, userspace having 
to url encode every parameter is neither clean nor intuitive.

Detecting whether the string is url-encoded before encoding seems like too much 
magic. It is fair to expect the oauth library to url encode,
 [2013-06-04 18:52 UTC] gregs at net-virtual dot com 
Sounds like we basicaally agree on that.

But the signature still seems to be wrong, wich presuming that's the same 
code being used to validate a key will break with clients that do it per-spec.
 [2013-06-04 18:56 UTC] jawed@php.net 
Thanks for the feedback.

Which clients are detecting URL encoded strings before deciding to encode them? 
IIRC the python oauth client does not do detection.
 [2013-06-04 18:59 UTC] gregs at net-virtual dot com 
You can try Chrome Postman plugin if you want.  It seems to comply with 
huniverse (though frankly it only takes a minute to plug this into that tool and 
I think you will see pretty clearly the step you are missing)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 23:01:27 2024 UTC