You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Da...@REQUISITE.com on 2003/09/29 18:54:33 UTC

Prompting user for authentication?

I've been working with HttpClient for the past few days and have it just
about working to my liking.  I must say I really like how it's designed!
However there's one bit that still bugs me...authentication of proxy and web
servers (response codes 401 and 407).  Basically, what I'd like to do is
prompt the user for the username/password when I get this response.  

What I've done for the moment is to subclass HttpState and override
getCredentials and getProxyCredentials such that they prompt the user for
the username and password if I don't already have credentials defined for
the realm/host combination.  This seems to work just fine except for NTLM
authentication.  This is because getCredentials doesn't know what scheme is
being used when the request is made.  So I don't know if I should display a
text field for domain or not.  I also don't know if I should be creating
UsernamePasswordCredentials or NTCredentials.

So my question is this:  Is there a better way to go about this?  Is there
something that could be added to HttpClient to support what I want to do?
Perhaps an interface AuthorizationPrompter (or whatever) that can be
registered with one of the library classes? (HttpClient? HttpState?)  Or
perhaps something I could subclass and override?

Thanks!
David
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. ²

Re: Prompting user for authentication?

Posted by Steve Vaughan <sn...@yahoo.com>.
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" <sn...@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


Re: Prompting user for authentication?

Posted by Adrian Sutton <ad...@intencha.com>.
On 30/09/2003 10:12 PM, "Steve Vaughan" <sn...@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


Re: Prompting user for authentication?

Posted by Steve Vaughan <sn...@yahoo.com>.
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

On Monday 29 September 2003 12:54 pm, David.Hay@REQUISITE.com wrote:
> I've been working with HttpClient for the past few days and have it just
> about working to my liking.  I must say I really like how it's designed!
> However there's one bit that still bugs me...authentication of proxy and
> web servers (response codes 401 and 407).  Basically, what I'd like to do
> is prompt the user for the username/password when I get this response.
>
> What I've done for the moment is to subclass HttpState and override
> getCredentials and getProxyCredentials such that they prompt the user for
> the username and password if I don't already have credentials defined for
> the realm/host combination.  This seems to work just fine except for NTLM
> authentication.  This is because getCredentials doesn't know what scheme is
> being used when the request is made.  So I don't know if I should display a
> text field for domain or not.  I also don't know if I should be creating
> UsernamePasswordCredentials or NTCredentials.
>
> So my question is this:  Is there a better way to go about this?  Is there
> something that could be added to HttpClient to support what I want to do?
> Perhaps an interface AuthorizationPrompter (or whatever) that can be
> registered with one of the library classes? (HttpClient? HttpState?)  Or
> perhaps something I could subclass and override?
>
> Thanks!
> David
> 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


Re: Prompting user for authentication?

Posted by Roland Weber <RO...@de.ibm.com>.
Hello David,

on second thought, if you want some kind of automatic handling,
you can try to substitute a different HttpMethodDirector (in 2.1).
There's probably no public API for that yet, but it's the perfect
place for such stuff.

regards,
  Roland



Re: Prompting user for authentication?

Posted by Roland Weber <RO...@de.ibm.com>.
Hello David,

we kind of tried the same approach with OpenCard. It wasn't funny
and never really worked satisfactory. Don't do it in the Http Client.

Instead of using a modified HttpState that interacts with the user,
just disable automatic authentication. Then, the application will get
the 401/407 response code, has full access to all headers, can
determine the type of authentication, and present a suitable user
interface. Then explicitly repeat the request with the authentication
information.

regards,
  Roland






David.Hay@REQUISITE.com
29.09.2003 18:54
Please respond to "Commons HttpClient Project"
 
        To:     commons-httpclient-dev@jakarta.apache.org
        cc: 
        Subject:        Prompting user for authentication?


I've been working with HttpClient for the past few days and have it just
about working to my liking.  I must say I really like how it's designed!
However there's one bit that still bugs me...authentication of proxy and 
web
servers (response codes 401 and 407).  Basically, what I'd like to do is
prompt the user for the username/password when I get this response. 

What I've done for the moment is to subclass HttpState and override
getCredentials and getProxyCredentials such that they prompt the user for
the username and password if I don't already have credentials defined for
the realm/host combination.  This seems to work just fine except for NTLM
authentication.  This is because getCredentials doesn't know what scheme 
is
being used when the request is made.  So I don't know if I should display 
a
text field for domain or not.  I also don't know if I should be creating
UsernamePasswordCredentials or NTCredentials.

So my question is this:  Is there a better way to go about this?  Is there
something that could be added to HttpClient to support what I want to do?
Perhaps an interface AuthorizationPrompter (or whatever) that can be
registered with one of the library classes? (HttpClient? HttpState?)  Or
perhaps something I could subclass and override?

Thanks!
David
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. ²