mn-dev / oauth Goto Github PK

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);
}

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.

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.

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

[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.

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.

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

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.

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.

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.

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.

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.

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.

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

they don't really work as written

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.

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)

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

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.

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>

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

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.

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

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.  

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. 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.

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

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.

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 ...

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

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()

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.

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!)

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

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

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.

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.