Hi Sergey,
sorry, we had a meeting right after I started to answer.
> 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?).
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.
> 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.
Greetings,
Peter
[1] http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-280003.3.4
