Ok...thanks! -----Original Message----- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 10:00 AM To: Commons HttpClient Project Subject: RE: Prompting user for authentication?
David, Regarding release target dates, all I can do is to offer my guesstimates: HttpClient 2.0 release: Novemeber 2003 HttpClient 2.1 alpha1: January 2004 HttpClient 2.1 beta1: March 2004 HttpClient 2.1 release: May 2004 Oleg -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 17:32 To: [EMAIL PROTECTED] Subject: RE: Prompting user for authentication? Great! I'll look forward to that release then. (BTW, got a rough target date for release?) In the meantime, my current solution will work, as I don't *have* to support NTLM authentication just yet. I would suspect that any authorization callback handler would need to pass along the host, port, realm, authorization scheme and possibly the status code (so we'd know if this was a proxy authorization or not). Just to give an implementation idea, what I currently have is an iterface called AuthorizationPrompter that has a single method: public Credentials getCredentials( String realm, String host ); I can then register implementations of this with my custom HttpState subclass. Then, my HttpState subclass I have the following code: public synchronized Credentials getCredentials( String realm, String host ) { Credentials credentials = super.getCredentials( realm, host ); if ( credentials == null ) { credentials = promptForCredentials( realm, host ); if ( credentials != null ) { setCredentials( realm, host, credentials ); } } return credentials; } there's a similar method for getProxyCredentials. Of course, the "if (credentials == null)" should probably live in the calling method, but that's the idea. Thanks! David -----Original Message----- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 7:46 AM To: Commons HttpClient Project Subject: RE: Prompting user for authentication? Steve, Integrated callbacks are planned for the next release (currently designated as 2.1) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794 Oleg -----Original Message----- From: Steve Vaughan [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 3:19 PM To: Commons HttpClient Project Subject: Re: Prompting user for authentication? I disagree. It seems counter-intuitive to me that every application that uses HttpClient should have to provide the same block of code to perform a function as fundamental as authentication. HttpClient already handles most authentication, but doesn't currently allow for any form of user interaction. An added benefit of using an integrated callback handler is the additional information available when authentication is required. Although the code you provided is able to test the status code for a 401, it does not know what forms of authentication are available. You could analyze the response header yourself, but this is already being performed by HttpClient. -Steve On Tuesday 30 September 2003 08:30 am, Adrian Sutton wrote: > On 30/09/2003 10:12 PM, "Steve Vaughan" <[EMAIL PROTECTED]> wrote: > > One of our engineers developed a patch for HttpClient which allows a > > callback handler to be registered with an HttpClient instance. A > > registered handler could prompt the user for username/password. When a > > handler isn't registered, the HttpClient works as it does now. > > > > -Steve > > The recommended way (at least as far as I'm concerned) of doing this is to > do it outside of HttpClient since it is in effect outside of what a HTTP > library should handle. The HTTP library handles talking to the server, > your code handles displaying the appropriate GUI and dealing with errors. > So what you do is deal with an unauthorized response like you would other > recoverable errors (excuse the poor code, Entourage keeps capitalising > things): > > For (int count = 0; count < MAX_ATTEMPTS; count++) { > GetMethod get = new GetMethod("http://auth.com";); > int response = httpclient.execute(get); > if (response >= 200 && response < 300) { > // Yay it worked. > } else if (response == 407) { > // Authorization required (I think 407 is right) > showAuthDialogAndSetCredentials(theRealm, isNTLM,...); > // Lets give them unlimited authorization attempts > count = 0; > } else if (response == 404) { > // Aw shucks, we're out of luck. > } else if (...) { > // redirect ? > // Server too busy, try again later > } > } > > That's the basic idea anyway. I thought everyone used that pattern with > HttpClient anyway? > > Regards, > > Adrian Sutton. > > ---------------------------------------------- > Intencha "tomorrow's technology today" > Ph: 38478913 0422236329 > Suite 8/29 Oatland Crescent > Holland Park West 4121 > Australia QLD > www.intencha.com > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CONFIDENTIALITY NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender ("Information") that may be confidential and legally privileged. If you are not the intended recipient, any disclosure, copying,distribution or action taken in reliance on the Information is strictly prohibited. If you have received the Information in error,please contact the sender by reply email and destroy all copies of the original email. Thank you. ¹ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CONFIDENTIALITY NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender ("Information") that may be confidential and legally privileged. If you are not the intended recipient, any disclosure, copying,distribution or action taken in reliance on the Information is strictly prohibited. If you have received the Information in error,please contact the sender by reply email and destroy all copies of the original email. Thank you. ¹
