Detect user deny authorization (Google)

[GoogleCodeExporter]

What steps will reproduce the problem?
Googel OAuth
1. getRequestToken 
2. Authorize 
3. User selects Deny (cancel)
4. Callback is called (requestToken seems to be authorized)
5. getAccessToken generates OAuthExpectationFailedException 

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

If user selects "deny" during authorization, Google seems to consider the 
requestToken to be authorized with no indication of user "denied". When 
trying the exchange the requestToken to accessToken Google responds with 
400 Bad Request (The request token is invalid). 

I think 400 should be represented as a specific exception e.g 
OAuthInvalidRequestTokenException or if this is common practice between 
all/most providers OAuthAuthorizationDeniedException

What version of the product are you using? On what operating system?
signpost-core-1.2

Please provide any additional information below.

Original issue reported on code.google.com by zuperglu...@gmail.com on 8 Feb 2010 at 8:12

[GoogleCodeExporter]

The problem here is that this is probably Google specific. Other service 
providers 
may indicate the denial of access using other means (such as calling back to 
the 
consumer or other status codes).

The standard is really unclear about this, unfortunately.

The standard suggests, however, to respond with 400 during token requests on 
the 
following conditions:

* Unsupported parameter
* Unsupported signature method
* Missing required parameter
* Duplicated OAuth Protocol Parameter

Thus, having a 400 throw OAuthAuthorizationDeniedException could be highly 
misleading, if not wrong.

I see the problem, however, that it's currently not straight forward to handle 
these 
cases, but at the moment, I don't see any way of doing this in a way that's 
portable 
across all OAuth service providers.

Original comment by m.kaepp...@gmail.com on 8 Feb 2010 at 9:04

[GoogleCodeExporter]

Would it be possible to store the "raw" HTTP status/message from provider, 
which could 
be retrieved as method call?

Original comment by zuperglu...@gmail.com on 8 Feb 2010 at 9:42

[GoogleCodeExporter]

certainly, if the provider set one. I could certainly add an 
OAuthBadRequestException, 
which would be thrown on a 400, and which had the error message sent by the 
provider 
set, if there was any.

Original comment by m.kaepp...@gmail.com on 8 Feb 2010 at 9:47

[GoogleCodeExporter]

Looking into the code you already detect 401 and map that to 
OAuthNotAuthorizedException.

Could you not map 400 similar e.g OAuthBadRequestException?

Both are "allowed" in spec as means to reject "Consumer requests"

It is somewhat different than current response: 
OAuthExpectationFailedException(
                    "Request token or token secret not set in server reply. "
                            + "The service provider you use is probably buggy.");

Original comment by zuperglu...@gmail.com on 8 Feb 2010 at 9:57

[GoogleCodeExporter]

Hum, you responded with my proposal before I "submitted". Cool... 

Original comment by zuperglu...@gmail.com on 8 Feb 2010 at 9:59

[GoogleCodeExporter]

You have a good point, I'll change that with the 1.2.1 maintenance release I 
had 
planned anyway. Just give me some time, have my hands full with work right now, 
so it 
could take a couple weeks.

Original comment by m.kaepp...@gmail.com on 8 Feb 2010 at 10:02

• Changed state: Accepted

[GoogleCodeExporter]

Would be great to log the error response when http response code is not 200. It 
could 
be part of exception message as well.

            if(statusCode!=200){
                InputStream errorStream=connection.getErrorStream();
                if(errorStream!=null){
                    BufferedReader reader = new BufferedReader(new 
InputStreamReader(errorStream));
                    StringBuilder errorString = new StringBuilder();
                    String line = reader.readLine();
                    while (line != null) {
                        errorString.append(line);
                        line = reader.readLine();
                    }
                    errorString.toString();
                    OAuth.debugOut("Http Response Error Body", 
errorString.toString());
                }
            }

Cheers!

Original comment by mrdu...@gmail.com on 20 Feb 2010 at 1:51

[GoogleCodeExporter]

Hi,

I have changed the service provider implementation to attach the response body 
to the
exception, if the provider replies in error.

more precisely, both OAuthNotAuthorizedException (401) and
OAuthCommunicationException (anything non-200 and non-401) now have a method
getResponseBody() which contains the error XML (or whatever is served by the 
provider).

The reason why I didn't add a OAuthAuthorizationDeniedException is that 
authorization
denial is completely underspecified in the spec. In fact, most providers don't 
seem
to do anything at all on denial. Twitter simply displays a page saying "you 
denied
this app access" and then sits there doing nothing. At Qype we redirect to the
frontpage, which is also less than optimal I guess :-)

Point being, before I can do anything portable here, it has to be specified how 
a
denial is communicated to the consumer.

Original comment by m.kaepp...@gmail.com on 12 Mar 2010 at 2:59

• Changed state: Started

Attachments:

• signpost-core-1.2.1-SNAPSHOT.jar

[GoogleCodeExporter]

Original comment by m.kaepp...@gmail.com on 14 Mar 2010 at 10:06

• Changed state: Fixed