May be I can add a property to support authorization retransmits without WWW-Authenticate

Sergey
On 25/10/16 12:42, Sergey Beryozkin wrote:
Well, WWW-Authenticate is there to indicate to the client that the
Authorization needs to be completed, this is standard HTTP. 401 alone
can mean anything, for example, the client password or user name may be
wrong, or the server can use 401 for some other reasons related to the
access of some of its resources (may be instead of 403).
At least with WWW-Authenticate CXF can try to generalize
and support various involved schemes.

HttpConduit.handleRetransmits() will trigger processRetransmit, you may
need to return 'true' from you you custom supplier's
requiresRequestCaching().

Cheers, Sergey

On 25/10/16 12:23, Konrad Windszus wrote:
I do have the issue that WrappedOutputStream.processRetransmit is not
even triggered, so it does not even reach the authorizationRetransmit
method. What might be the issue here?

On 25 Oct 2016, at 13:12, Konrad Windszus <konra...@gmx.de> wrote:

This is a 3rd party server I unfortunately cannot influence.
Any way to to modify the WWW-Authorize handling in CXF?
Where is the piece of code being responsible for triggering the
retransmit evaluating the WWW-Authorize header?

Thanks,
Konrad
On 25 Oct 2016, at 12:23, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

Hi

Why can't the server return WWW-Authenticate ?

Cheers, Sergey
On 25/10/16 11:04, Konrad Windszus wrote:
Thanks for that tip. Unfortunately my custom HttpAuthSupplier is
only called once (before the request is triggered). No matter
whether I return null or the empty string in my getAuthorization
method my HttpAuthSupplier is not called a second time. The reason
is that the underlying close method on the HTTPConduit is never
called, therefore handleRetransmits on the WrappedOutputStream is
never called.
What am I doing wrong?
In my case there is no WWW-Authorize response header being used but
just a plain 401 status to indicate that authentication should be
triggered.
Internally I am using a JAX-RS Client proxy which always fails with
javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
    at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

    at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at
org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:504)

    at
org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:314)

    at
org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:793)

    at
org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:755)

    at
org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)

...

Thanks for any help,
Konrad


On 19 Oct 2016, at 12:32, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

Hi

AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is
returned and a custom CXF HttpAuthSupplier is registered.

For example, see

https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java


In your custom supplier you'd override:
public String getAuthorization(AuthorizationPolicy authPolicy,
                                URI currentURI,
                                Message message,
String fullHeader) {}

perhaps you'd do the extra calls inside this method before
returning the final Authorization value for the original request
to continue

Sergey




On 17/10/16 08:45, Konrad Windszus wrote:
I want to call a ReST web service with a JAX-RS client based on
CXF. That web service has a custom authentication based on
cookies and challenge/response authentication. To get
authenticated (i.e. whenever a regular call returns a 401) a
dedicated GET request must be issued to get the challenge, and
then an additional POST request to authenticate the user (and get
back an authentication token as cookie). Instead of doing the
authentication explicitly I would rather call that whenever
necessary (to also deal with cases where previous authentication
became invalid), i.e. as Interceptor or as Filter. The question
is, how do I retrigger the original request once the user has
been successfully authenticated in a ClientResponseFilter or
Interceptor in case a 401?
Has someone ever implemented something like this?
Thanks,
Konrad



--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/



--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/






--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Reply via email to