php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60252 Signature issues with none-standard HTTP Methods
Submitted: 2011-11-09 18:29 UTC Modified: -
Votes:10
Avg. Score:4.2 ± 1.2
Reproduced:9 of 10 (90.0%)
Same Version:9 (100.0%)
Same OS:6 (66.7%)
From: ahmad at codeinchaos dot com Assigned:
Status: Open Package: oauth (PECL)
PHP Version: 5.3.8 OS: Ubuntu/Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
31 - 10 = ?
Subscribe to this entry?

 
 [2011-11-09 18:29 UTC] ahmad at codeinchaos dot com
Description:
------------
I could be wrong in my understanding of oAuth 1.0a ... so I'm sorry if the 
following does not apply:

the extension doesn't seem to be able to sign requests with a custom HTTP Method 
(verb) with a payload ...

ex:
curl -iH "Authorization: OAuth {PARAMS-HERE}" -d 
"value1=foo&value2=foo2&value3=foo3 -X LINK http://domain.tld/api

signature always fails, because the extension does not grab the payload for none 
POST requests.

Expected result:
----------------
the oaugh signature should always use the payload body params regardless of the 
HTTP Method.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-11-15 01:10 UTC] hubert at muchlearning dot org
Related, but not exactly the same issue: there also seems to be errors when verifying the signature when there is more than one parameter with the same name, or if array parameters are sent (e.g. parameters of the form "foo[0]=bar", presumably because it is looking at $_POST instead of looking at the raw POST data.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 17:01:30 2024 UTC