Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
Date: 29 Jan 2004 09:16:07 -0000
Message-ID: <20040129091607.22089.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-httpclient-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 10794]  -
    User interaction for authentication

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=10794>.
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=10794

User interaction for authentication


------- Additional Comments From ortwin.glueck@nose.ch  2004-01-29 09:16 -------
I think this patch goes to far. Currently credentials are stored inside
HttpState. This makes it very flexible to use HttpClient either from stock or
create your own methods or even replace the HttpClient completely. So I would
rather keep HttpState the place where to ask for credentials from within HttpClient.

What we need and what the patch already contains is a callback to retrieve
credentials. But the CredentialsPrompter beeing a monostate limits the
flexibility of the credentials retrieval. Whether the prompter is a single
instance for multiple HttpClients or if there are multiple instances should be a
decision of the user.

I suggest not to implement the CredentialsPrompter. Instead just provide
HttpState::setCredentialsCallback(CredentialsCallback) and change the
get[Proxy]Credentials methods to use the callback. We can still leave the
credential setters in for convenience and handle them through a default
implementation of the callback.

The advantages are:
 * user can easily choose which callback to use for which HttpClient instance
 * preemptive auth does not break
 * simpler code
 * less API change

I will provide a patch in a minute to explain my ideas.

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