kooyeed / oauth Goto Github PK

Line 203 of OAuth.php at rev 569 reads

      else if ($http_method = "POST") {

should read

      else if ($http_method == "POST") {

(test equality vs. assignment)

When php receives parameter like 'a[b]=test', 
it creates for it entry like 'a' => array('b' => 'test'). 

OAuthRequest is initialized with $_POST or $_GET values,
thus sometimes it receives arrays as parameter value. 
It's not easy to escape an array or use it in signature ; ) 

OAuthRequest needs to be initialized with array 
having only scalars as values. 

Following patch implements OAuthRequest::get_flat_post()
method and uses it to populate OAuthRequest parameters.

The OAuth specification allows the service provider to accept or require
additional parameters when issuing a request token.  The service provider
would generally want to store that information in its token store for
future reference (e.g. to make decisions about resource access).

The OAuthServer / OAuthDataStore split doesn't seem to provide a way to
store this information since the OAuthDataStore.fetch_request_token()
method doesn't get passed this information.

The spec also allows for additional parameters passed to the authorisation
URL and access token URL, so it might make sense to pass those parameters
to fetch_access_token() too.  I am not sure whether
authorize_request_token() needs them.

What steps will reproduce the problem?
1. OAuth.decodeForm('')

What is the expected output? What do you see instead?
Expected: []
Actual result: ['', null]

What version of the product are you using? On what operating system?
r675

Please provide any additional information below.

OAuth.decodeForm is used to derive the base string. If the message action is 
'http://example.com/rest/?', decodeForm is called with an empty string. Instead 
of returning an 
empty list of form paramaters, it returns an empty parameter. This then creates 
the wrong base 
string, so the OAuth signature cannot be verified.

Solution:

In the decodeForm method, instead of:

            list.push([name, value]);

Use:

            if (name) {
              list.push([name, value]);
            }

From 5.4.1 (http://oauth.net/core/1.0/#auth_header)

The authorization header contains oauth protocol parameters. These are ones 
that start with 
"oauth_", but in the python libs, the oauth header ends up containing even 
query string params.

What steps will reproduce the problem?
1. Use client.py (official oauth example python code) to make a GET request 
with one query 
string param in the url
2. Set http headers to oauth_request.to_header() for          
self.connection.request(oauth_request.http_method, oauth_request.http_url, 
headers=oauth_request.to_header())
3. Run GET request, the authorization header has "sort=date" as well

What is the expected output? What do you see instead?
While verification does not fail, it can mess up frameworks (like grails) that 
auto-populate the 
query string/post vars. Even in PHP for example, you would no longer be able to 
use the $_GET 
or $_POST superglobals to access those extra params

What version of the product are you using? On what operating system?
OS X, Python 2.5, Oauth python lib, custom groovy/grails-based provider using 
Java libs

Patch provided. (One-liner!)

The URL to the SVN repository on the Source tab is wrong.
It specifies:
http://oauth.googlecode.com/svn/trunk/
which does not exist.

It should be: 
http://oauth.googlecode.com/svn/

Cheers!
Shonzilla

1.  We don't want to use a "Consumer Secret" because our consumers are
going to be distributed/open source/unsecurable and we don't want to give
the wrong idea, can we use OAuth?

Yes.  Consumer Secrets may be an empty string.  (I know its like the 2nd
line of the document, but still its a FAQ)  Additionally as an SP you could
track whether a Consumer Secret was used and assign different trust levels
to Tokens.  

By testing the obj-c (rev 587) oAuth library against our oAuth supported
API system we found a problem with the signature calculation.

The key used for the HMAC_SHA should be url-encoded separately before
joined, as defined in the oAuth spec (http://oauth.net/core/1.0/#anchor16).
Currently, the 2 secrets that are joined together aren't url-encoded at all.

A patch will be provided next week.

Kilian Marjew
Hyves.nl

[this bug is in reference to the Python library]

The specification describes a set of cases where a 400 response is
appropriate, and another set of cases where a 401 response should be used
instead.

All these cases seem to generate an OAuthError exception (or in some cases
by returning None).  This makes it difficult to produce a relevant error
response.

What steps will reproduce the problem?

1. Create a class implementing the OAuthDataStore interface
2. Use it for an OAuth server

What is the expected output? What do you see instead?

The OAuthServer class should call the "fetch_" functions, since that's
what's documented for the interface. Instead, it calls the "new_"
functions, which are what's actually implemented in the Simple class. If
the new_ functions aren't implemented, PHP throws an unimplemented-method
exception.

Probably the best fix would be to simply change the "fetch_" functions to
"new_" functions in the abstract OAuthDataStore class, so that implementers
know what they should really implement. It's more of a documentation error
than anything else.

What version of the product are you using? On what operating system?

PHP library, latest version as of this issue.

Please provide any additional information below.

OAuthRequest::split_header() receiver header as it came over http. 
Spec says that header should look like this:

Authorization: OAuth realm="http://sp.example.com/",
oauth_consumer_key="0685bd9184jfhq22",
....

Note the 'OAuth' part which specifies authorization type.
OAuthRequest::split_header() doesn't strip it before
parsing, and also throws away everything not starting 
with 'oauth_', thus first parameter is always lost, 
whether it is unused (?) realm or any other oauth parameter.

Attached patch fixes this behaviour simply.

What steps will reproduce the problem?
1. Add a body that is not "application/x-www-form-urlencoded"
2. Create a Signature Base String.
3. Witness that form body is in SBS.
4. Also, PUTs have the body in the SBS, regardless of Content-Type.

What is the expected output? What do you see instead?
Per "9.1.1.  Normalize Request Parameters," only POSTs with a Content-Type of 
application/x-
www-form-urlencoded" should have the body included in the SBS.

What version of the product are you using? On what operating system?
SVN Revision: 580

Please provide any additional information below.
Patch and unit tests included. This patch supercedes the one I posted on 
RubyForge.

As per the discussion in this thread:
http://groups.google.com/group/oauth/browse_thread/thread/6ae9b3f6177683aa

The PHP OAuth library should sign request parameters in the URL query part.

I have attached the patch to this bug. Please let me know if you need any
additional clarifications regarding the bug or patch. 

Thank you,
Chirag Shah
Email: [email protected]

Currently, OAuthSignatureMethod is an empty class. I think it would make
sense to change it into an interface like:

interface OAuthSignatureMethod {
    function get_name();
    function build_signature($request, $consumer, $token);
}

The SimpleOAuthClient example's access_resource() function uses POST, but
does not set the content-type. Some web servers (e.g. Tomcat) will not
identify that the content contains HTTP parameters unless the content-type
is set properly.

Something like this works for me:
    def access_resource(self, oauth_request):
        # via post body
        # -> some protected resources
        headers = { 'Content-Type' :'application/x-www-form-urlencoded' }
        self.connection.request('POST', RESOURCE_URL,
body=oauth_request.to_postdata(), headers=headers)
        response = self.connection.getresponse()
        return response.read()

Can someone confirm that the changes to the standard URL encode in the
OAuth class are correct as I can't find the part of the OAuth spec that
specifies this. Isn't this going to cause signature problems if clients
don't conform to this non-standard encoding?

Code is:

 return URLEncoder.encode(s, ENCODING)
                    // OAuth encodes some characters differently:
                    .replace("+", "%20").replace("*", "%2A")
                    .replace("%7E", "~");

I have had problems with signatures using the java library connecting to
Yahoo's FireEagle application (fireeagle.yahoo.com). Double quotes (")
seemed to cause a problem when they were part of a parameter value. I'm
afraid I haven't been able to confirm the problem but investigation led me
to the URL encode and thus this issue request.

What steps will reproduce the problem?
use the library on an OS that is case sensitive for filenames, errors will
be thrown as CF will be unable to locate the required component file.

What version of the product are you using? On what operating system?
rev 626, Coldfusion 8.0.1 / Centos 5

Please provide any additional information below.

The library references components using camel-case but all component
filenames are lowercase

CreateObject("component", "OAuthToken") --> oauthtoken.cfc

suggested fix for this problem is to rename all files, using the correct
camel-casing e.g OAuthToken.cfc

In line 365 of OAuth.php there's an extra double-quote being prepended to
the Authorization header:

    $out ='"Authorization: OAuth realm="' . $realm . '",';

This causes the header to be set as:

    "Authorization: OAuth ...

OAuthSignatureMethod_PLAINTEXT::build_signature() returns 
already urlencoded value. This breaks OAuthServer::check_signature()
as it compares urlDecoded value from request with urlEncoded value
generated with build_signature. 

build_signature should not escape returned value, as it will be escaped 
later in OAuthRequest::to_postdata(). See [1] for example of once-encoded
ampersand in plaintext signature.

[1]: http://oauth.net/core/1.0/#anchor27

What steps will reproduce the problem?

Sign a request using OAuthSignatureMethod_HMAC_SHA1 and examine the value
of sResult before it is returned from
OAuthSignatureMethod_HMAC_SHA1.buildSignature()

What is the expected output? What do you see instead?

currently the library is not url encoding the basestring before signing it.
 for example: 

POST&http://api.domain.com/login/request&oauth_consumer_key=111222333&oauth_nonc
e=833C7083155C6DAD6E874796B77414670D447FDB&oauth_signature_method=HMAC-SHA1&oaut
h_timestamp=1218443250&oauth_version=1.0


The expected base string should be: 

POST&http%3A%2F%2Fapi.domain.com%2Flogin%2Frequest&format%3Djson%26oauth_consume
r_key%3D111222333%26oauth_nonce%3DE4A29C58631066226567BA13165E626D067760CA%26oau
th_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1218443373%26oauth_version%3
D1.0


What version of the product are you using? On what operating system?
rev: 626

Please provide any additional information below.

Below is an updated buildSignature function that will correctly url encode
each portion of the base string.  Please note the use of
java.net.URLEncoder to do the url encoding and NOT coldfusion's built in
urlEncodedFormat() function. urlEncodedFormat will (incorrectly?) encode
".", "-" and "_" to their % values causing the signature to be invalid.

<!--- builds a SHA-1 signature --->
<cffunction name="buildSignature" access="public" returntype="string">
    <cfargument name="oRequest"     required="true" type="OAuthRequest">
    <cfargument name="oConsumer"    required="true" type="OAuthConsumer">
    <cfargument name="oToken"       required="true" type="OAuthToken">

    <cfset var encoder = createObject("java", "java.net.URLEncoder") />
    <cfset var aSignature = ArrayNew(1)>
    <cfset var sKey = "">
    <cfset var sResult = "">
    <cfset var sHashed = "">
    <cfset var digest = "">

    <cfset ArrayAppend(aSignature,
encoder.encode(arguments.oRequest.getNormalizedHttpMethod()))>
    <cfset ArrayAppend(aSignature,
encoder.encode(arguments.oRequest.getNormalizedHttpURL()))>
    <cfset ArrayAppend(aSignature,
encoder.encode(arguments.oRequest.getSignableParameters()))>

    <cfset sKey = arguments.oConsumer.getSecret() & "&">
    <cfset sKey = sKey & arguments.oToken.getSecret()>
    <cfset sResult = ArrayToList(aSignature, "&")>

    <cfset sHashed = hmac_sha1(
        signKey = sKey,
        signMessage = sResult)>

    <cfreturn sHashed>
</cffunction>

final keyword on OAuthMessage is preventing ability to subclass and change
values.

Photobucket API required manipulation of the URL after the signature has
been calculated so please remove the final keyword on the OAuthMessage
variables.

What steps will reproduce the problem?
1. Call OAuth.setParameters(message,parameters) with 'parameters' as null
and 'message' as anything
2. Observe failure due to OAuth.getParameterList returning null and this
not being checked for before assuming the return value has a 'length' property

What is the expected output? What do you see instead?
You expect a string output. Instead, the function throws an error.

What version of the product are you using? On what operating system?
oauth.js, revision 564, Mac OS X 10.4.11, Safari 3.1.1, FireFox 2.0.0.14

Please provide any additional information below.
Patch file attached. Note this problem could also occur in
OAuth.getBaseString and OAuth.normalizeParameters, but not in
OAuth.formEncode, which checks for a null return value. The method used in
the patch is the same as in OAuth.formEncode.

If I access example/client.php I get the following notices:

Notice: Undefined variable: req_token in
/home/dho/projects/test/app/webroot/example/client.php on line 66

Notice: Undefined variable: req_token in
/home/dho/projects/test/app/webroot/example/client.php on line 67

See summary. Two real issues:

#1 OpenSSL isn't present on iPhone SDK. (also Security.framework does contain 
functions HMAC-
SHA1)
#2 Keychain APIs aren't all present on SDK.

I've resolved these two issues and am about to check in the code. Creating this 
issue to track 
change.

OAuthDataStore has lookup_nonce method, but nonce generation is placed in
OAuthRequest::generate_nonce, which doesn't have access to storage. I
think there should be OAuthDataStore::new_nonce() method. I'm submitting 
a preliminary patch for this, however  currently it breaks examples because of 
changed from_consumer_and_token() signature. 

What steps will reproduce the problem?
1. provide a callback
2. call to_url() to put it in the the GET parameters

What is the expected output? What do you see instead?

resulting url has 'http://' replaced with 'http%253A%252F%252F' instead of
'http%3A%2F%2F' (the '%' gets encoded again)

What version of the product are you using? On what operating system?
  current trunk, os doesnt matter

Please provide any additional information below.

What steps will reproduce the problem?
1. Have a web server listening on port 80
2. Run the example code at
http://groups.google.com/group/opensocial/web/validating-signed-requests-from-or
kut
3. Look at the value of $req->get_normalized_http_url() 

What is the expected output? What do you see instead?
Expect to see: http://domain.tld/file.php
Actually see: http://domain.tld:/file.php

Please provide any additional information below.
The OAuth.php library expects PHP to return "80" for $parts['port'] where
$parts = parse_url($this->http_url); for a server listening on port 80.  It
does not though, in line with the manual:
http://www.php.net/manual/en/function.parse-url.php

Attached is a patch to fix bug, and remove a duplicate line.

[Spec says](http://oauth.net/core/1.0/#anchor22): 

oauth_signature is set to the concatenated encoded values of the Consumer 
Secret and Token Secret, 
separated by a ‘&’ character (ASCII code 38), even if either secret is 
empty. The result MUST be encoded 
again.

oauth.py doesn't append ampersand for request token and doesn't escape values 
passed to 
Authentication header. Attached patch fixes this.

The Python example server implements the request token URL using
OAuthServer.fetch_request_token().

If the consumer passes an oauth_token parameter to the request token URL
for a valid request token, fetch_request_token() will return that token
without any signature checking rather than checking the signature and
creating a new token.  The existing token and its secret are then returned
to the consumer.

You might need a bit more information to perform a successful attack, but
leaking this information seems like a problem.  There should probably be
separate methods for use by the "request token" and "authorisation" stages.

I think it would be more flexible if OAuthDataStore is an interface instead
of a class.

What steps will reproduce the problem?

1. Make a PLAINTEXT OAuth call with the OAuth parameters in the POST body.

What is the expected output? What do you see instead?

Ampersands in the oauth_signature POST parameter should be encoded just
once (%26). Instead they're double encoded (%2526), causing problems with
some service providers.

What version of the product are you using? On what operating system?

r678 of OAuth.php

Please provide any additional information below.

The following diff to OAuthSignatureMethod_PLAINTEXT::build_signature()
appears to remedy the issue, however I haven't tested it extensively to see
if it causes issues in other parts of the code:

-     return OAuthUtil::urlencodeRFC3986($raw);
+     return $raw;

Step:

1. GET http://some.domain.com/?q=x/y
2. Encode signature with HMAC-SHA1

Result:
parameter list is double urlencoded - should be x%2Fy when submitted for
sha1 encoding, instead is x%252Fy

Encoding happens on line 337 and 359

ALSO

1. signature is generated that contains + character
2. signature is not urlencoded
3. + is received at other end and converted into space

the signature needs to be urlencoded after generation (see line 236)

What steps will reproduce the problem?
1. Consumer Request Send. using HTTP Authorization header and HMAC-SHA1
2. Response "Invalid signature"


What is the expected output? What do you see instead?
Response "oauth_token=requestkey&oauth_token_secret=requestsecret"


What version of the product are you using? On what operating system?
windows xp
apache 2.2.6
php-5.2.6


Please provide any additional information below.

OAuthRequest::split_header

It fails.

sample code
--
$param = "oauth_signature=wOJIO9A2W5mFwDgiDvZbTSMK/PY=";
$param_parts = explode("=", $param);
print_r($param_parts);
--

result
--
Array
(
    [0] => oauth_signature
    [1] => wOJIO9A2W5mFwDgiDvZbTSMK/PY
    [2] => 
)
--

The patch was made. 


I am an English amateur.
Please pardon it. 

it might be wrong. 
I am an OAuth amateur.

thanks

Spec says ([1]) that tilda ('~') is unreserved character 
and MUST NOT be encoded. However php library escapes 
parameters using urlencode(), which converts tilda to '%7E'. 
Only in one place library fixes that. 

Attached patch introduces OAuthServer::paramEncode() method  
which does the job right. It replaces urlencode() everywhere in 
library. 

[1]: http://oauth.net/core/1.0/#encoding_parameters

Maven (http://maven.apache.org/) is a software project management and
comprehension tool. When a java project provides a POM descriptor it ease
the adoption of the library to other developers that use maven to build
their projects.

Here is a patch that add maven support to oauth. As side effect, now you
can run the example applications without needing any servlet
container..simply from the command line:

juan@dinah ~/src/oauth/example/oauth-provider $  mvn
org.mortbay.jetty:maven-jetty-plugin:run

starts a servlet container that it can be accessed using:
   http://localhost:9090/oauth-provider/

(Also it would be nice to get the jars and poms deployed at
http://repo1.maven.org/maven2/)

Regards,
   Juan.

Just a suggestion. Although I feel safe to assume that this is covered
under the MIT license of the entire gcode "oauth" project, this would make
it a bit more clear if people get linked directly to the code.

Please add public keyword declaration to HttpMethodResponse so object can
be subclassed without having to put subclass in same package.

What steps will reproduce the problem?
1. Build OAuthConsumer Xcode project (esp. UnitTests)
2. Watch as testInitWithKeychainUsingAppName fails!

What is the expected output? What do you see instead?
Not a failure

Not 100% sure why the UnitTests are breaking. I need to compare code before my 
changes and see 
if I broke the UnitTests in  http://code.google.com/p/oauth/issues/detail?id=22

Unfortunately I don't have time to investigate and fix right now, but thought 
I'd at least file a bug

This bug report is for the Python OAuth module.

The build_signature_base_string() method of OAuthSignatureMethod_PLAINTEXT
does not match the interface described by the OAuthSignatureMethod base
class, returning a single string rather than a pair of strings.

This causes a ValueError exception in OAuthServer._check_signature() when a
request is invalid (see the "if not valid_sig:" block).  If
OAuthSignatureMethod_PLAINTEXT correctly implemented the interface, a more
informative OAuthError would be produced.

What steps will reproduce the problem?
1. install Google Android SDK 1.0 R1
2. install oauth-1.3.jar

I want to use the oauth-1.3 jar within my Android application. As far as I
can tell, oauth-1.3 is dependent upon Apache HttpClient 3.1

Unfortunately for me, the Android platform uses the Apache HttpClient 4 API.

Is the OAuth 1.3 Java library compatible with Apache HttpClient 4.x ?  

Note:  the HttpClient 4 API is not compatible with the HttpClient 3.x API

If somebody only wants to use the client he should not be forced to pull in
the servlet dependency.

The same thing for the commons-httpclient dependency, maybe have a generic
client and add the commons version to a separate module.

Something linke this:
OAuth-core
OAuth-client
OAuth-server
OAuth-client-httpclient

There is a bug in the c# library when generating the baseSignature. 

Method: public string GenerateSignatureBase

            signatureBase.AppendFormat("{0}&",
UrlEncode(normalizedRequestParameters));
            signatureBase.AppendFormat("{0}&", UrlEncode(consumerSecret));
            signatureBase.AppendFormat("{0}", UrlEncode(tokenSecret));

should be removed and replaced with 

            signatureBase.AppendFormat("{0}",
UrlEncode(normalizedRequestParameters));

I tested with the testcase outlined in http://oauth.net/core/1.0/#anchor30,
Appendix A.5.1. the secret tokens shouldn't be included in the
signatureBase according to the expected output. Now my oAuth lib
modifications work with hyves.net api 0.9, not sure if this is wrong
behavior on their side or in the oAuthBase code.

they don't really work as written

It should be noted that users should be able to change their passwords with 
Service Providers 
without invalidating existing tokens. Password management can be separate from 
token 
management.

It's important for Consumer app developers to keep in mind that Users may have 
multiple accounts 
with the same Service Provider and that tokens should be able to be stored for 
each remote 
account. WordPress.com is a good example of this where a user may have multiple 
blogs to which 
she can post, and may use an application like MarsEdit or Ecto to severally 
post to them.

This is also true, but less likely, for Flickr accounts, where a single user 
may have access to or 
posting rights, to several Flickr accounts. Consumer applications should 
determine whether they 
support one account at a time or multiple.

Step:

1. GET http://some.domain.com/?q=x
2. Authorized by HTTP Header or HTTP POST

Result:

the signature does not match

Version:

Python/oauth/oauth.py r481

OAuthRequest::from_request should look only look at $_POST for POST requests 
and $_GET for 
everything else.

When I try to contact Google for a request token I got following message:

/-------------------------------------------------
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=UTF-8
Date: Mon, 06 Oct 2008 12:40:03 GMT
X-Content-Type-Options: nosniff
Expires: Mon, 06 Oct 2008 12:40:03 GMT
Cache-Control: private, max-age=0
Content-Length: 48
Server: GFE/1.3

parameter_absent
oauth_parameters_absent:scope
/-------------------------------------------------

/-------------------------------------------------
My request message, like it is:
https://www.google.com/accounts/OAuthGetRequestToken?
oauth_consumer_key=<my consumer key>&
oauth_signature_method=HMAC-SHA1&
oauth_timestamp=1223296800&
oauth_nonce=5407853365278&
oauth_signature=<my signature>
/-------------------------------------------------

/-------------------------------------------------
My request message, like it should be:
https://www.google.com/accounts/OAuthGetRequestToken?
oauth_consumer_key=<my consumer key>&
oauth_signature_method=HMAC-SHA1&
oauth_timestamp=1223296800&
oauth_nonce=5407853365278&
oauth_signature=<my signature>&
scope=http://picasaweb.google.com/data
/-------------------------------------------------

And, It makes sense, because the google scope parameter is required.
But, how can I add an required parameter in the request token message??
Theres a method called "addRequiredParameters" in OAuthMessage class that  
append the OAuth required attributes by Spec.. but how about the required
parameters added by Service Provider??

Help guys! XD 

Where can OAuth be used?  Is it just for the web?

Most OAuth service providers will have websites where Users can
authenticate and grant permissions.  However OAuth Consumers can, will, and
do run on all sorts of platforms including desktop applications, mobile and
set top devices, as well as on the Web.

What steps will reproduce the problem?
1. appeal to existent
2. too good to bee
3. tru

What is the expected output? What do you see instead?
non identity

What version of the product are you using? On what operating system?
non monetary 

Please provide any additional information below.