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/
