cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: CXF OAuth2 AuthorizationCodeGrantService in Karaf
Date Tue, 20 Nov 2012 10:08:30 GMT
Hi Peter
On 20/11/12 09:16, Peter Schyma wrote:
> Hello Sergey,
>
> I found some time today in the morning to test it, finally.
>
> It works like a charm. Having a RequestDispatcherProvider provider
> configured to dispatch OAuthError to a specific JSP I get the custom
> HTML view for the error.
>
Very good, thanks for spending the time

> Do you need additional tests on it?

It works for you so that is good enough for me. I'll resolve CXF-4633 
for now - please reopen in case some more relevant fixes are needed

Cheers, Sergey

>
> Peter
>
> Am 13.11.2012 18:09, schrieb Sergey Beryozkin:
>> Hi
>>
>> I've typed some code to get the error reported without enforcing JSON
>> enforced too early in the case when the error needs to be returned
>> directly to the client:
>>
>> http://svn.apache.org/viewvc?rev=1408832&view=rev
>>
>> Can you experiment with this code please in a day or two, after the
>> snapshots have been redeployed ?
>>
>> Thanks, Sergey
>>
>> On 12/11/12 15:16, Sergey Beryozkin wrote:
>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>


Mime
View raw message