ashu8826 / oauth-signpost Goto Github PK

What steps will reproduce the problem?
1. Attached is the twitter example showing the problem

I am not sure if this is a Jaiku issue or signpost but I get the following
exception:

Exception in thread "main"
oauth.signpost.exception.OAuthCommunicationException: Communication with
the service provider failed: URLDecoder: Illegal hex characters in escape
(%) pattern - For input string: " a"

I will continue to investigate and update accordingly.

It looks like the callback parameter given to retrieveRequestToken in the
DefaultOAuthProvider is hex encoded twice, resulting in an incorrect signature.

A first time at the line 70 of the class:

retrieveToken(OAuth.addQueryParameters(requestTokenEndpointUrl,
                OAuth.OAUTH_CALLBACK, OAuth.percentEncode(callbackUrl)));

And the second time a few steps later in the addQueryParameters method.

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

SVN version on android.

Java 1.6 class files were reported to cause problems with Android.

When obtaining an Unauthorized Request Token, the request must be signed 
http://oauth.net/core/#auth_step1) However, at that point a Token Secret is not 
available. The 
specification allows for this in section 9.2. HMAC-SHA1 
(http://oauth.net/core/#anchor16) by 
not requiring a Token Secret (the implication is that it's the url-encoded 
consumer secret 
followed by an "&" and nothing else)

HmacSha1MessageSigner.java:25
 String keyString = OAuth.percentEncode(getConsumerSecret()) + '&' + 
OAuth.percentEncode(getTokenSecret());

Which depends on oauth.signpost.OAuth.percentEncode, which depends on 
com.google.gdata.util.common.base.PercentEscaper, which fails with an NPE if 
the Token Secret 
is null.

A quick fix is to add a test in oauth.signpost.OAuth.percentEncode and just 
return an empty 
string in the parameter is null.

With that fix, I could access Twitter using OAuth.

What steps will reproduce the problem?

I am creating the request tokens out-of-band.  The DefaultOAuthProvider
will set isOAuth10a to true in retrieveRequestToken() and I get the
consumer token and token secret, which I store for later use.

I need to reconstitute the OAuthProvider at a later time to invoke
retrieveAccessToken() with the PIN that the user enters.  I can create the
DefaultOAuthConsumer and initialize the token and token secret.  The
OAuthProvider, though, has isOAuth10a set to false by default and there is
no way to set it to true (no setter method and it is a private property).

As such, I always get an HTTP 401 error.

In Eclipse, I can set a breakpoint before the call to retrieveAccessToken()
and reach behind the scenes and set isOAuth10a to true before the call is
made and I get a successful HTTP 200 return.

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

I would expect there to be some way to programatically initialize
isOAuth10a to true.

I could create my own implementation that is essentially a copy of
DefaultOAuthProvider, but with a setter for isOAuth10a; however, I'd rather
not replicate code and have to keep them in sync.

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

snapshot-core-1.1-SNAPSHOT downloaded 2009.06.24

Please provide any additional information below.  Here is the example
Twitter code modified to emulate complete reconstitution of the consumer
and provider.

public static void main(String[] args) throws Exception {

        OAuthConsumer consumer = new DefaultOAuthConsumer(
                CONSUMER_KEY,
                CONSUMER_SECRET,
                SignatureMethod.HMAC_SHA1);

        OAuthProvider provider = new DefaultOAuthProvider(consumer,
                "http://twitter.com/oauth/request_token",
                "http://twitter.com/oauth/access_token",
                "http://twitter.com/oauth/authorize");

        System.out.println("Fetching request token from Twitter...");

        // we do not support callbacks, thus pass OOB
        String authUrl = provider.retrieveRequestToken(OAuth.OUT_OF_BAND);

        System.out.println("Request token: " + consumer.getToken());
        System.out.println("Token secret: " + consumer.getTokenSecret());

        System.out.println("Now visit:\n" + authUrl
                + "\n... and grant this app authorization");
        System.out.println("Enter the PIN code and hit ENTER when you're
done:");

        BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));
        String pin = br.readLine();

        String requestToken = consumer.getToken();
        String requestTokenSecret = consumer.getTokenSecret();

        // Save the requestToken and requestTokenSecret away.  Pretend the rest
        // of this is a whole new thread with reconstituted consumer/provider.

        System.out.println("Fetching access token from Twitter...");

        OAuthConsumer consumer2 = new DefaultOAuthConsumer(
                CONSUMER_KEY,
                CONSUMER_SECRET,
                SignatureMethod.HMAC_SHA1);

        consumer2.setTokenWithSecret(requestToken, requestTokenSecret);

        OAuthProvider provider2 = new DefaultOAuthProvider(consumer2,
                "http://twitter.com/oauth/request_token",
                "http://twitter.com/oauth/access_token",
                "http://twitter.com/oauth/authorize");

        // Here I can set a breakpoint in Eclipse, reach behind the scenes
        // and set provider2's isOAuth10a to true and it will work
        provider2.retrieveAccessToken(pin);

        System.out.println("Access token: " + consumer.getToken());
        System.out.println("Token secret: " + consumer.getTokenSecret());

        URL url = new URL("http://twitter.com/statuses/mentions.xml");
        HttpURLConnection request = (HttpURLConnection) url.openConnection();

        consumer2.sign(request);

        System.out.println("Sending request to Twitter...");
        request.connect();

        System.out.println("Response: " + request.getResponseCode() + " "
                + request.getResponseMessage());
    }

What steps will reproduce the problem?
1.
I create a provider:
 OAuthProvider provider = new DefaultOAuthProvider(consumer,
                REQUEST_TOKEN_ENDPOINT_URL, ACCESS_TOKEN_ENDPOINT_URL,
                AUTHORIZE_WEBSITE_URL);
where AUTHORIZE_WEBSITE_URL is:
"http://myaccount-nightly.us2.global.ad/userservices-myaccount/myaccount/confirm
_access?us_oauth_method=onestep
that is, it contains an extra parameter

2.
I get a request token
String authorizeRequestTokenUrl = provider.retrieveRequestToken(CALLBACK_URL);

The returned URL is
http://myaccount-nightly.us2.global.ad/userservices-myaccount/myaccount/confirm_
access?us_oauth_method=onestep?oauth_token=51895058-4178-4a89-9ead-6cd969691e47&
oauth_callback=http%3A%2F%2Fmy.domain.com

and it is incorrect, it contains two '?' because
DefaultOAuthProvider.retrieveRequestToken does not check the existence of
'?' in the URL.
3.

What is the expected output? What do you see instead?
DefaultOAuthProvider.retrieveRequestToken should check the existence of
parameters in the URL and if there is one then it should append '&' instead
of '?' as a starter for oauth parameters. 

The OAuth spec 1.0, chapter 6.2.1 states that additional parameters are
accepted so Signpost should support those.


What version of the product are you using? On what operating system?
1.0-SNAPSHOT on Mac OSX


Please provide any additional information below.

Service Provider, the timestamp is expressed in the number of seconds since 
January 1, 1970 
00:00:00 GMT

The current implementation uses milliseconds:

DefaultOAuthConsumer.java:97
map.put(OAuth.OAUTH_TIMESTAMP, Long.toString(System.currentTimeMillis()));

Google's OAuth implementation checks the timestamp and issues a "timestamp is 
too far from 
current time" error if milliseconds are used.

Dividing by 1000 fixes the problem (and lets me access the Google Portable 
Contacts API using 
OAuth)

Signpost needs to be updated to reflect the changes imposed by OAuth Core
1.0a. The library must remain backwards compatible with 1.0 service providers.

Draft 3 of OAuth Core 1.0a spec:
http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/3/

Seth Fitzsimmons was already so kind to contribute a patch which adds 1.0a
support:
http://github.com/mojodna/oauth-signpost/commit/0bc5a7bafc3c4829907d9c8033848bcc
e509a7af

What remains to do:

1) Patch trunk with Seth's changesets (or maybe open a branch for 1.0a?)
2) Write tests for 1.0a changes
3) Write tests that check whether Signpost works with both 1.0 and 1.0a
providers

If I don't care about specific error conditions, I'd like to write a simplified 
`catch` (for a single type of OAuth exception).

Thoughts?

Signpost should support gzip encoding by default (for more effective use of 
slow (cell) networks).

What steps will reproduce the problem?
1. When exchanging a request token for an access token Signpost generates
an URL like this

http://localhost:8080/userservices/oauth/access_token?oauth_token=a4d14ddb-3eaf-
4706-8693-eaabc2e21c84&oauth_token_secret=lHX2uM6CM77eqPTzMniigIoRWCpSkAYwwXBq/7
FOyCQEcu2jKQVs4Rp9k7ADQEG24MLByTnOKMXNZOQXiWZH9YKvPuJCEw4OH/ik3kN4wy0=

that is, outh_token_secret is sent to OAuthProvider - this is not needed
and it is a security risk.

Further, having aouth_token encoded as part of the Http GET URL is in
contradiction with what is stated in the Signpost documentation that says
that OAuth parameters are sent as part of the Http Authorize header.

And yes, oauth_token is also sent as part of the Authorize header! This
means that the signature base to used to produces the signature looks like
this:

GET&
http%3A%2F%2Flocalhost%3A8080%2Fuserservices%2Foauth%2Faccess_token&
oauth_consumer_key%3Dmyphone%26
oauth_nonce%3D1242810500517710000%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1242810500%26
oauth_token%3D82afaed0-42ea-4129-a914-2f53d42e7346%26
oauth_token%3D82afaed0-42ea-4129-a914-2f53d42e7346%26
oauth_token_secret%3DjOvfP3mjn7z%252FDJXVaaMuLwoLRR2EVxfFnFEbbLBlhbZMBBweD2hSREt
UghfL1LFVl7QbpNvKpb%2520926oeJR3ZlzdtGuaAT8YCvSrQ7IVXlxM%253D%26
oauth_version%3D1.0   

Note that oauth_token occurrs twice.

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

I would propose to 
A) remove the oauth_token_secret from URL
B) remove the oauth_token from URL
It is enough to generate an URL like this:
http://localhost:8080/userservices/oauth/access_token

What version of the product are you using? On what operating system?
1.0-SNAPSHOT on Mac OSX

Please provide any additional information below.
I encountered this problem when I got 401 for this request, my Provider
being developed with Spring Oauth/Security. Spring drops the double
oauth_token and uses this signature base string

GET&
http%3A%2F%2Flocalhost%3A8080%2Fuserservices%2Foauth%2Faccess_token&
oauth_consumer_key%3Dmyphone%26
oauth_nonce%3D1242810500517710000%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1242810500%26
oauth_token%3D82afaed0-42ea-4129-a914-2f53d42e7346%26
oauth_token_secret%3DjOvfP3mjn7z%252FDJXVaaMuLwoLRR2EVxfFnFEbbLBlhbZMBBweD2hSREt
UghfL1LFVl7QbpNvKpb%2520926oeJR3ZlzdtGuaAT8YCvSrQ7IVXlxM%253D%26
oauth_version%3D1.0 

In order to do get request token and get access token in different threads,
it is necessary to save the provider object. Having a serializable instance
simplifies storing and re-creation. 

Signpost should be decoupled from concrete HTTP implementations so that it
becomes useful for environments that do not use the Apache HttpComponents.

Tasks:
1) Introduce interface abstractions for message signing (i.e. HttpRequest)
2) Provide implementations via adapter classes (e.g. for Apache, Jetty, etc.)
3) Distribute library in implementation specific JARs (e.g. signpost-jetty.jar)

Please discuss.

What steps will reproduce the problem?

1. Try signing an HttpUrlConnection object without setting token and token-
secret parameters (that would be the case for 2 legged scenario)
2. Check the signature base string
3. Check the generated OAuth signature

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

Signature base string should include "auth_token=&" as per section 9.1.1. 
of the OAuth specs. However, the auth_token is completely ignored due to 
being empty (which will always be true for 2-legged scenario) and is 
missing from the signature base string. 
The oAuth signature generated as a result is wrong. As a verification, it 
doesn't match the signature generated by the reliable online resource - 
http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html

What version of the product are you using? On what operating system?
Latest as of yesterday (July 14, 2009)

Please provide any additional information below.