Hi Peter
On 12/11/12 14:34, Peter Schyma wrote:
Hi Sergey,
sorry, we had a meeting right after I started to answer.
no problems, whenever you get the time to reply is OK
> My understanding it won't be OAuth2 compliant, returning the error
to do
> with the (illegal) client directly to the end user ?
...
> Can you clarify please when would you like to get the error
returned as
> HTML representation ?
But it is returning the JSON to the end user. We are in the current
redirection based flow:
1. Client requests
"/authorize?client_id=X&redirect_uri=Y&response_type=code&..."
2. Client is validated
3. Based on the result of the validation:
3a. An authorization form is shown to the end user, or
3b. an error is raised
In case 3a the user sees a HTML page (or JSON/ XML depending on the
request headers) that describes the request and asks for the
authorization. Independent of the decision a redirect is made to the
client.
Case 3b should now display the error in a human friendly manner or
handle it appropriately (e.g. redirect to client with error code?).
Actually, you are right. The spec says that the client validation
failure should result in the error returned directly to the end user.
Currently, in CXF the following is happening in case 3b.
1. OAuthDataProvider#getClient is called to obtain the client instance
2. Regardless of whether OAuthDataProvider#getClient returns a null
value or raises an exception, a new WebApplicationException (even
discarding the OAuthError from the original exception) is thrown by
calling AbstractOAuthServer#reportInvalidRequest.
Here I can only register OAuthJSONProvider or a custom Provider that
pretends to render JSON but actually renders something else.
Sure, I'll deal with it...
> Not really, the mapper will have a chance to update Response already
> available in the caught WebApplicationException, but eventually it
will
> be up to the providers (MBW) to handle the actual response
The spec [1] says that I should not be able to do this. The
WebApplicationExceptions that is thrown out of
AbstractOAuthServer#reportInvalidRequest contains already an entity that
must be used.
Interesting. I guess at the moment CXF will let custom
WebApplicationException mappers to modify the original Response
available from WebApplicationException, but it is really up to the
custom mapper if that is to be done or not, definitely not something
that CXF itself will do (ie, it won't modify the custom
WebApplicationException resposne if any).
I'll probably seek some clarifications on this specific point. IMHO the
custom mapper should be able to see all WebApplicationException
instances, even the ones which may already contain Response, example,
for some custom logging purposes
Thanks, Sergey
Greetings,
Peter
[1]
http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
