commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul C. Bryan" <>
Subject Re: [HttpClient] Support for Basic and Form-based authentication ?
Date Thu, 03 Jan 2002 22:20:09 GMT
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.

Yours truly,

Paul C. Bryan <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message