hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David....@REQUISITE.com
Subject RE: Prompting user for authentication?
Date Tue, 30 Sep 2003 16:00:51 GMT
Ok...thanks!

-----Original Message-----
From: Kalnichevski, Oleg [mailto:oleg.kalnichevski@bearingpoint.com]
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: David.Hay@REQUISITE.com [mailto:David.Hay@REQUISITE.com]
Sent: Tuesday, September 30, 2003 17:32
To: commons-httpclient-dev@jakarta.apache.org
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:oleg.kalnichevski@bearingpoint.com]
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:snmvaughan92@yahoo.com]
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" <snmvaughan92@yahoo.com> 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:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional
> commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


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


---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
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:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
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. ¹

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message