Within my limited understanding this all seems fine to me.
On Wed, Dec 22, 2010 at 2:39 PM, Christian Schneider <[email protected]> wrote: > 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 > >
