cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Request for feedback: Refactoring of HTTP client authentication
Date Wed, 22 Dec 2010 19:39:16 GMT
I have now refactored the authentication of the http transport so the 
basic auth is now supported by DefaultBasicAuthSupplier. Spnego is now 
also supported using a SpnegoAuthSupplier.

As I have changed some of the behaviour I would like to get some 
feedback before committing this.
Please also see:
https://issues.apache.org/jira/browse/CXF-3216

Basic, Digest and Spnego / Kerberos auth can now be configured by simply 
setting the AuthType in the AuthorizationPolicy. The HttpConduit then 
creates a HttpAuthSupplier on the fly if none is configured explicitly. 
Still an AuthoriationPolicy on the message overrides the 
AuthorizationPolicy on the Conduit.

I have also added a system test for DigestAuthSupplier as I changed the 
code and wanted to make sure it really works against a jetty insstance.

There are some possible compatibility issues with my patch:

    * The first thing is that the HttpAuthSupplier is cached so it is
      created only once. If you later change the Authtype the supplier
      will stay the same. This can be solved by deleting the
      authSupplier so it is recreated.
    * The HttpAuthsupplier now overrides the AuthorizationPolicy on the
      message. Before the AuthorizationPolicy on the message would
      override the AuthSupplier. I don?t think anyone really would use this
    * If the message content is to be cached is now only determined by
      calling the requiresRequestCaching method on the authsupplier.
      Before the authSupplier was also asked for
      premptiveAuthentication. If this did not return null the message
      was also cached. I think this is not necessary as the authsupplier
      can still decide if caching is needed.
    * Currently you can set authType and authorization on the
      authorizationPolicy. This is then used to directly create the
      authorization header. This is used by the old spnego interceptor I
      added recently. I removed this feature as it is only really usable
      in an interceptor and it can be done better by creating a custom
      authSupplier

Additionally I would like to remove the feature of setting an 
AuthorizationPolicy on the message. This would allow us to make the 
authsuppliers independent of conduit and message in the future.

I also would like to introduce an authSupplier for proxy auth and 
handling of 407 responses so we can support multi phase authentications 
with a proxy.

-- 
----
http://www.liquid-reality.de


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message