commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 8140] - Incorrect credentials loop infinitely
Date Wed, 10 Jul 2002 04:39:41 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8140>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8140

Incorrect credentials loop infinitely

jsdever@sympatico.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsdever@sympatico.ca
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME



------- Additional Comments From jsdever@sympatico.ca  2002-07-10 04:39 -------
I'm not sure when or how this is fixed, but it appears to be working well.

I tried it with both setting the default credentials as a startSession()
argument and by adding particular credentials for a specific authentication
realm with setCredentials().

In HttpMethodBase.execute, the following code checks to see if an authentication
was done on the "<path>:<type> realm=<realm>" string.  If it has, then it
breaks
out and returns from execute.  If it has not been tried, it sets the
authentication and trys again.
<code>
                    if (realms.contains(pathAndCreds)) {
                        if (log.isInfoEnabled()) {
                            log.info("Already tried to authenticate to \"" +
wwwauth.getValue() + "\" but still receiving " + HttpStatus.SC_UNAUTHORIZED +
".");
                        }
                        break;
                    } else {
                        realms.add(pathAndCreds);
                    }
</code>
That being said, the code above is in a for(;;) loop with some complicated code
in it.  It does have some good error checking code in there for infinite
re-direction and such, but I have not attempted to test all the possibilities.

Perhaps the reporter of this bug could re-test and provide a more detailed test
scenario if it still occurs.

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message