commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: [HttpClient] Support for Basic and Form-based authentication ?
Date Thu, 03 Jan 2002 22:58:27 GMT


> -----Original Message-----
> From: Paul C. Bryan [mailto:email@pbryan.net]
> Sent: 03 January 2002 22:20
> To: Jakarta Commons Developers List
> Subject: Re: [HttpClient] Support for Basic and Form-based
authentication
> ?
> 
> Vincent Massol wrote:
> 
> > Is the following algorithm non-standard ? :
> >
> > * Try to call a given secured page
> > * In the HTTP response, check if a Location header field matching a
> > given page (the login page) has been returned. If so, it means we
need
> > to log the user
> > * Get the jsession id cookie from the returned response
> > * Send a POST request to j_security_check, passing the following in
the
> > request :
> > - jsession id cookie,
> > - j_username POST parameter,
> > - j_password POST parameter
> > * Retry the original URL
> >
> > In the end, the user either get the requested page or some failure
page
> > defined by the application (we could decide not to handle failure
page
> > in HttpClient or we could handle it).
> >
> > In summary the parameters to pass to HttpClient from the application
> > would be :
> > - login page
> > - servername + contextRoot (for building the j_security_check URL :
> > http:// + serverName + contextRoot. Ex:
http://my.server:8080/mywebapp)
> > - user name
> > - password
> >
> > Am I missing something ? From your list of issues, ack and failure
could
> > be left to applicationm, state mechanism is standard for Servlets
API
> > .... ahah maybe here is the trick. What you are saying is that it is
non
> > standard across technologies. Right, but at least it is standard in
a
> > given technology, like Servlets, so maybe we could provide a
> > ServletFormAuthentication that would extend FormAuthentication
(which
> > would have a setUserNameParameterName(), setPasswordNameParameter(),
> > setSecurityCheckURL() and setSessionCookieName()), which would
itself
> > extend Authentication (which would have the notion of username,
password
> > of the client side API and validation of username/password, HTTP
> > configuration and response handling on the SPI side ?
> 
> 
> The purpose of the HttpClient library is to provide a full client
> implementation of the HTTP protocol, such that any application can use
> it to implement an HTTP client.
> 
> What you are proposing is the addition of application-specific support
> for authentication with a Java Servlet using form-based
authentication.
> In my opinion, this is outside the scope of the HttpClient.
> 
> Such a library could be built using the HttpClient library, extending
it
> to support server-specific authentication methods using a flexible and
> extensible architecture.
> 
> Such a library should remain separate and distinct from HttpClient
IMHO.
> 
> If, sometime in the future, an HTTP standard emerges that provides
> form-based authentication, I'd be supportive of its inclusion in the
> HttpClient library.
> 

I think I agree with you ... ;-). Let's keep it outside of HttpClient
(unless other chime in and think it should be in in which case we could
reopen the discussion).

However, what would be nice is to provide authentication interfaces so
that it is possible for an application to plug in its own authentication
scheme. 

Do you know If this already exists ? If so, is there some documentation
or could you explain in a few words how I would plug in my own
authentication scheme ?

Thanks Bryan. I appreciate your help.
-Vincent

> Yours truly,
> 
> Paul C. Bryan <email@pbryan.net>
> http://pbryan.net/
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
> 




--
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