HTTPCLIENT-1748: fix for proxy authentication issue / branch 4.5.x

[sebastiencaille]

Hello,
Here is a pull request for HTTPCLIENT-1748 for httpclient 4.5.x. The first change is the fix, the second one is an improvement.

I also implemented the fix for httpclient5. Should I submit it as a separate pull request, or do you have a specific way to handle such case? (rebase, ...)

Thanks

[ok2c]

Sebastien
What was the reason for changing AuthScope class and including a URL attribute in the auth scope? Based on my reading of the HTTP spec authentication context is defined by the realm of the auth challenge, not by a request URI.
Oleg

[sebastiencaille]

Hello

At first I tried to provide the proxy's url, but the applet was always asking for credentials.
It works fine when I provide the request URI.
Then, according to a breakpoint I put in Authenticator.requestPasswordAuthentication, the applet plugin uses the url of the jar files it wants to download.

I just checked the code of the openjdk... It looks like they are doing that, too
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/net/www/protocol/http/HttpURLConnection.java#HttpURLConnection.getHttpProxyAuthentication%28sun.net.www.protocol.http.AuthenticationHeader%29 (line 2223)

My guess is that the other parameters are sufficient to define the realm of the auth challenge. That one is probably used to strengthen the security in some use cases (eg to reduce the risks of cross domain calls).

By the way, it looks like providing HTTP_TARGET_HOST is sufficient to fix my use case, but strictly speaking it should be the entire request URI (but at the moment I don't know how to get that one)...

Sebastien

[ok2c]

Sebastien,
Nothing should stop you from getting the actual request URI by reading the HTTP_REQUEST attribute.

Adding the request URI to the AuthScope class looks conceptually wrong and should not be done simply because Oracle does it.

[sebastiencaille]

Ok, I'll use HTTP_REQUEST

my point about the openjdk was just that we need to provide this value, nothing more...
At the moment I see it as a "security metadata" for AuthScope, which is required to make requestPasswordAuthentication work correctly in all cases.

As far as I get it, the other option is to add a parameter to CredentialsProvider.getCredentials...
eg getCredentials(AuthScope authscope, HttpContext httpContext).
But that's a much larger change...

Sebastien

[ok2c]

I have no problem of what so ever with changing CredentialsProvider in 5.0 if it is justified.

[ok2c]

I have a question. Why cannot you build the URL from AuthScope attributes if effectively you only need the authority part (scheme://host:port)?

[sebastiencaille]

When the java application is run in an applet environment (and webstart, possibly), The Authenticator delegates the call to a com.sun.deploy.security.DeployAuthenticator . The DeployAuthenticator only works when the url parameter of requestPasswordAuthentication is the url I want to connect to (eg http://www.whatever.com - the jdk provides the full url, it works with the authority part), it does NOT work if the url parameter is the proxy url (http://myproxy:3128) - I guess the authentication is delegated to the browser, which needs this information for security reasons (maybe to prevent cross domain calls). Since the AuthScope only contains information about the proxy, the information needed to call requestPasswordAuthentication the "right" way is currently not available...

[ok2c]

Obsoleted by #55. Please close