hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Glück (JIRA) <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-620) If CredentialsProvider is not interactive, but programmatic (e.g. fetches credentials from database) and credentials are wrong the httpclient will attempt to connect until network connections limit is exhausted on the machine and will not fail.
Date Fri, 12 Jan 2007 08:08:27 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464115
] 

Ortwin Glück commented on HTTPCLIENT-620:
-----------------------------------------

The API Doc of CredentialsProvider says:

"HttpClient makes no provisions to check whether the same credentials have been tried already.
It is a responsibility of the custom credentials provider to keep track of authentication
attempts and to ensure that credentials known to be invalid are not retried. HttpClient will
simply store the set of credentials returned by the custom credentials provider in the http
state object and will attempt to use these credentials for all subsequent requests with the
given authentication scope."

Is that not feasible for your case?

> If CredentialsProvider is not interactive, but programmatic (e.g. fetches credentials
from database) and credentials are wrong the httpclient will attempt to connect until network
connections limit is exhausted on the machine and will not fail.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-620
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-620
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.0.1
>         Environment: Windows XP, Java 5.
>            Reporter: Andriy Proskuryakov
>
> Happens if CredentialsProvider is not interactive (does not bring dialog every time it
is asked for credentials), but programmatic (e.g. fetches credentials from database).
> If credentials returned by provider are wrong the httpclient will not fail after few
attempts to connect, but will continue attempts to connect until network connections limit
is exhausted on the machine.
> Instrumenting getCredentials method shows it being called hundreds of times in a matter
of few seconds, netstat will show hundreds of connections in the TIME_WAIT state.
> I believe the executeMethod of the HttpMethodDirector is responsible (loop on line 141).
If processAuthenticationResponse (line 192) fails, the retry is set to true and it attempts
to connect again.
> Here is stack trace dumped from getCredentials:
> java.lang.Exception: Stack trace
> 	at java.lang.Thread.dumpStack(Unknown Source)
> 	at com.beacon.proxy.impl.CredentialPreferences.getCredentials(CredentialPreferences.java:30)
> 	at org.apache.commons.httpclient.HttpMethodDirector.promptForProxyCredentials(HttpMethodDirector.java:892)
> 	at org.apache.commons.httpclient.HttpMethodDirector.processProxyAuthChallenge(HttpMethodDirector.java:772)
> 	at org.apache.commons.httpclient.HttpMethodDirector.processAuthenticationResponse(HttpMethodDirector.java:665)
> 	at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:192)
> 	at org.apache.commons.httpclient.ProxyClient.connect(ProxyClient.java:202)
> 	at com.beacon.proxy.impl.TunnelingSocketFactory.createSocket(TunnelingSocketFactory.java:101)
> 	at com.beacon.proxy.impl.SecureSocketFactory.createSocket(SecureSocketFactory.java:89)
> 	at com.beacon.proxy.impl.SecureSocketFactory.createSocket(SecureSocketFactory.java:65)
> 	at com.beacon.commons.net.ConnectionTypeSocketFactory.createSocket(ConnectionTypeSocketFactory.java:26)
> 	at com.beacon.proxy.ConnectionChecker$1.run(ConnectionChecker.java:72)
> We made a hack to circumvent this for our use (just allow few attempts) and then exit.
Below is the patch.
> You would certainly want something better for the fix, but the patch can help in understanding
the problem:
> Index: src/java/org/apache/commons/httpclient/HttpMethodDirector.java
> ===================================================================
> --- src/java/org/apache/commons/httpclient/HttpMethodDirector.java	(revision 11183)
> +++ src/java/org/apache/commons/httpclient/HttpMethodDirector.java	(working copy)
> @@ -138,7 +138,11 @@
>          try {
>              int maxRedirects = this.params.getIntParameter(HttpClientParams.MAX_REDIRECTS,
100);
>  
> -            for (int redirectCount = 0;;) {
> +            int authattempts = 0;
> +            // Stop trying to connect if the number of authentication attempts exceeds
6.
> +            // Chose 6, an even number twice 3, because NTLM requires two challenges
per
> +            // authentication attempt.
> +            for (int redirectCount = 0; authattempts < 6;) {
>  
>                  // make sure the connection we have is appropriate
>                  if (this.conn != null && !hostConfiguration.hostEquals(this.conn))
{
> @@ -191,6 +195,7 @@
>                  if (isAuthenticationNeeded(method)) {
>                      if (processAuthenticationResponse(method)) {
>                          LOG.debug("Retry authentication");
> +                        ++authattempts;
>                          retry = true;
>                      }
>                  }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message