Duplicated and superfluous OAuth parameters in Http Request produced by Signpost

[GoogleCodeExporter]

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 

Original issue reported on code.google.com by erno.to...@gmail.com on 20 May 2009 at 12:22

[GoogleCodeExporter]

Thanks for reporting this. The token secret definitely doesn't belong in the 
query
string, that's a bug.

However, I think you are misunderstanding two important things. First, it seems 
as if
you are trying to pass a URL that is meant to provide an access token to the 
service
provider where instead it expects a URL to the authorization website (the one 
which
leads the user through the authorization procedure). Signpost never appends any 
query
parameters to the access token URL, so you seem to have constructed the service
provider object using wrong URLs. Can you please post the code snippet you use 
to
obtain an OAuthProvider instance here?

Second, having oauth_token (this is the *request* token, not the access token) 
appear
as a query parameter in the URL constructed by 
OAuthProvider.retrieveRequestToken()
is correct and entirely in accordance with the OAuth spec. In section 6.2.3 it 
is
stated that

"If the Consumer provided a callback URL in oauth_callback (as described in 
Consumer
Directs the User to the Service Provider), the Service Provider constructs an 
HTTP
GET request URL, and redirects the User’s web browser to that URL with the 
following
parameters:

    oauth_token:
        The Request Token the User authorized or denied. 

The callback URL MAY include Consumer provided query parameters. The Service 
Provider
MUST retain them unmodified and append the oauth_token parameter to the 
existing query."

It's just that in your case, the wrong URL is used.

Original comment by m.kaepp...@gmail.com on 20 May 2009 at 12:48

[GoogleCodeExporter]

There is no misunderstanding from my side, I'm afraid. 

1. The authorization process is over (successfully) when this URL we are 
discussing
is produced by Signpost when I call:

provider.retrieveAccessToken();

which looks like this in oauth.signpost.impl.DefaultOAuthProvider

    public void retrieveAccessToken() throws OAuthMessageSignerException,
            OAuthNotAuthorizedException, OAuthExpectationFailedException,
            OAuthCommunicationException {

        if (consumer.getToken() == null || consumer.getTokenSecret() == null) {
            throw new OAuthExpectationFailedException(
                    "Authorized request token or token secret not set. "
                            + "Did you retrieve an authorized request token before?");
        }

        retrieveToken(accessTokenEndpointUrl + "?" + OAuth.OAUTH_TOKEN + "="
                + consumer.getToken() + "&" + OAuth.OAUTH_TOKEN_SECRET + "="
                + consumer.getTokenSecret());
    }

2. There are several ways to send oauth params to the Provider, yes. Signpost 
has
chosen one way, read what you state on your site:
"The OAuth standard demands that OAuth request parameters may be put in the URI 
query
string or in the message payload. Signpost will never do that; instead, all 
OAuth
protocol parameters are written to the HTTP Authorization
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8>  header field.
Anything you put there will be overwritten by Signpost."

In the case of the request we are discussing the oauth_token is sent in the 
Authorize
header, as usual, (along with the rest of oauth params). That's OK for the 
standard
and complies to the Signpost documentation.

But the oauth_token is sent as URI query string AS WELL, which is, yes, 
superfluous
and it is in contradiction with the Signpost documentation.

I patched in Signpost by replacing the last call in the function above with
    retrieveToken(accessTokenEndpointUrl);

and everything worked fine, Signpost was happy, my Provider (based on Spring 
OAuth
extension to Spring Security) was happy too.

Original comment by erno.to...@gmail.com on 21 May 2009 at 7:09

[GoogleCodeExporter]

I see what you mean, I stand corrected! I'll look into that ASAP.

Original comment by m.kaepp...@gmail.com on 21 May 2009 at 10:18

[GoogleCodeExporter]

Geez, I have absolutely no idea how that code snippet made it in there, it makes
*absolutely* no sense... thanks again for reporting.

Original comment by m.kaepp...@gmail.com on 21 May 2009 at 10:27

[GoogleCodeExporter]

Original comment by m.kaepp...@gmail.com on 21 May 2009 at 10:27

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by r19.

Original comment by m.kaepp...@gmail.com on 21 May 2009 at 10:35

• Changed state: Fixed

[GoogleCodeExporter]

I still have at least one of my users (Android - DroidIn app) reporting this 
error. I
cannot reproduce it in Android emulator (1.5) but here's what the user is 
reporting

1. After initial request user is redirected to the Twitter site
2. User is authenticated and callback URL is executed
3. User is back to the app's activity that was called by callback URL
4. At this point the Exception is thrown and user sees the following message:
"Authorized request token or token secret not set.  Did you retrieve an 
authorized
request token before?"

So should I just ignore it at this point? Anyway - you can see a write up of 
what is
happening in my app on this page http://is.gd/1TgVH. Again - this does not 
occur for
all users (I cannot reproduce it) but for the user who reported it it happens 
all the
time

Original comment by bost...@gmail.com on 29 Jul 2009 at 9:52