Oleg Kalnichevski wrote:
Sebastiaan van Erk wrote:Hi Oleg,Thanks for your reply. There's a good chance I'm going to have to get this working, even if it means I'm going to have to delve into this myself. I'll contact the original developer and see if he sees anything obvious, but in any case,if I succeed in getting it working, I will happily contribute the patches.Best regards, SebastiaanHi Sebastiaan Cool. In my turn I will happily help with HttpClient specific stuff.
Hi Oleg,I got the proxy authentication working already. I even tested it when both proxy auth and http auth are required and it works.
There is just one small issue: I need the proxy host name to generate the kerberos service name (HTTP/proxyh...@realm). The current NegotiateScheme code doesn't handle proxy auth at all and always uses the target host name which it retrieves from the Host header (is that the best way to get the target host?):
if (isStripPort()) {
init((request.getLastHeader("Host")).getValue().replaceAll(":[0-9]+$",
"") );
} else {
init( (request.getLastHeader("Host")).getValue());
}
I changed the NegotiateScheme to extend AuthSchemeBase (like
NTLMScheme). Now I have access to the isProxy() method and can add the
correct header (Proxy-Authorization or Authorization). However, to
determine the hostname I currently have this:
String host;
if (isProxy()) {
// FIXME this should actually be determined by the route planner?
HttpHost proxy = ConnRouteParams.getDefaultProxy(request.getParams());
host = proxy.getHostName();
} else {
host = request.getLastHeader("Host").getValue();
}
if (isStripPort()) {
host = host.replaceAll(":[0-9]+$", "");
}
init(host);
I noticed a few frames up in DefaultRequestDirector.handleResponse the
actual proxy host is known:
if (this.proxyAuthHandler.isAuthenticationRequested(response, context)) {
HttpHost proxy = route.getProxyHost();
this.log.debug("Proxy requested authentication");
Map<String, Header> challenges =
this.proxyAuthHandler.getChallenges(response, context);
try {
processChallenges(challenges,
this.proxyAuthState, this.proxyAuthHandler,
response, context);
} catch (AuthenticationException ex) {
...
But this information is not available to me at the FIXME location. I'm
also ignoring any forced route now, but it seems wrong to copy paste the
code from DefaultHttpRoutePlanner anyway, especially since that's just
the default implementation anyhow and could be overridden.
Next thing I'll look into is why the redirect fails. Regards, Sebastiaan
Cheers OlegOleg Kalnichevski wrote:Sebastiaan van Erk wrote:Hi,I'm not sure it's supported yet in httpclient-4.1-alpha1, but continuing on my kerberos quest, I was trying the next phase: kerberos proxy authentication.This time I'm requesting a public url from the target server via a kerberos protected squid proxy. Again I tested this with firefox, and it works fine. (The final phase, kerberos proxy AND kerberos server, also works with firefox).However, when I add the following two lines to the Kerberos http client example:HttpHost proxy = new HttpHost("tunnelproxy.servoy.com", 3128);httpclient.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, proxy);The proxy authentication fails. It tries to authenticate to the service for the target web server instead of for the proxy service, that is, I get the following entry in my kdc.log:2009-12-11T14:22:12 TGS-REQ [email protected] from IPv4:85.147.225.232 for HTTP/[email protected]But for the proxy service you need a ticket to HTTP/[email protected].Is this a setup issue on my side, or is Kerberos proxy auth not yet supported, or is this a bug?Again I included the wirelog for further details. Best regards, SebastiaanSebastiaanI have some bad news for you. I suspect none of the actual HttpClient committers might be able to help you with Kerberos related problems. I, for one, have neither time nor inclination to dive into the subject. Kerberos code is fully based on user contributions. You may want to get in touch directly with the contributor of SPNEGO auth scheme [1] and _very politely_ ask him for help. I will happily review and commit patches, but my personal involvement will stop there.Oleg [1] http://issues.apache.org/jira/browse/HTTPCLIENT-523 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
