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

go to bug id or search bugs for

Bug #59337 SBS not encoded in ProblemReporting output
Submitted: 2010-08-04 03:41 UTC Modified: 2011-01-16 19:47 UTC
Votes:3
Avg. Score:3.7 ± 1.9
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:3 (100.0%)
From: php+bugs at dmi dot me dot uk Assigned:
Status: Open Package: oauth (PECL)
PHP Version: 5.3.2 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: php+bugs at dmi dot me dot uk
New email:
PHP Version: OS:

 

 [2010-08-04 03:41 UTC] php+bugs at dmi dot me dot uk 
Description:
------------
If there is a problem with the signature, the ProblemReporting extension echoes back the expected SBS. This needs to be urlencoded again before output, as otherwise arguments can be lost when parsing the result, and the wrong data will be returned.

Reproduce code:
---------------
curl -iH 'Authorization: OAuth realm="", oauth_nonce="blargh", oauth_timestamp="1280776749", oauth_consumer_key="consumer-key", oauth_signature_method="HMAC-SHA1", oauth_version="1.0", oauth_token="access-me", oauth_signature="83ziTTIbrIgoGIjqp541JaFzBms%3D"' -X PUT http://localhost/oauth/a_private_api.php

Expected result:
----------------
HTTP/1.1 401 Unauthorized
Date: Wed, 04 Aug 2010 07:36:46 GMT
Server: Apache
Content-Length: 306
Content-Type: text/html; charset=utf-8

oauth_problem=signature_invalid&debug_sbs=PUT%26http%253A%252F%252Flocalhost%252Foauth%252Fa_private_api.php%26oauth_consumer_key%253Dconsumer-key%2526oauth_nonce%253Dblargh%2526oauth_signature_method%253DHMAC-SHA1%2526oauth_timestamp%253D1280776749%2526oauth_token%253Daccess-me%2526oauth_version%253D1.0

Actual result:
--------------
HTTP/1.1 401 Unauthorized
Date: Wed, 04 Aug 2010 07:36:46 GMT
Server: Apache
Content-Length: 270
Content-Type: text/html; charset=utf-8

oauth_problem=signature_invalid&debug_sbs=PUT&http%3A%2F%2Flocalhost%2Foauth%2Fa_private_api.php&oauth_consumer_key%3Dconsumer-key%26oauth_nonce%3Dblargh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1280776749%26oauth_token%3Daccess-me%26oauth_version%3D1.0

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-15 13:27 UTC] jawed@php.net 
IIRC, it used to be double encoded but we decided to revert 
the debug SBS back to single encoding because of:

1) http://wiki.oauth.net/w/page/12238543/ProblemReporting

2) Consistency - Google's provider also did not double 
encode the debug SBS...that may have changed in which we can 
re-visit the issue.

- JJ
 [2011-01-16 14:37 UTC] php+bugs at dmi dot me dot uk 
As far as the ProblemReporting spec goes, I don't see any 
mention of "debug_sbs" (or signature base string) at all. 
However, it does state that "parameter values are percent-
encoded". In the examples for "oauth_paramenters_absent" and 
"oauth_parameters_rejected", it explicitly states that their 
values are double-encoded, so it is a reasonable assumption 
that debug_sbs should be.

Aside from that, not double-encoding debug_sbs makes it much 
more difficult to parse. I would therefore argue that it is 
a bug that should be addressed.
 [2011-01-16 17:07 UTC] jawed@php.net 
Yes, I agree that is more difficult to work with if it is not 
double encoded. I'm okay with changing it; Rasmus, Felipe, 
Tjerk any objections?

- JJ
 [2011-01-16 19:47 UTC] rasmus@php.net 
Ok with me.
 [2013-09-12 22:30 UTC] tim at timlytle dot net 
Here's a userland fix:

$headers = OAuthProvider::reportProblem($e, false);
if(strpos($headers, 'debug_sbs') !== false){
    $parts = explode('&', $headers, 2);
    array_walk($parts, function(&$value){
        $value = str_replace('&', '%26', $value);
    });
    $headers = implode('&', $parts);
}
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Nov 22 00:01:30 2024 UTC