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:06:25 GMT


> -----Original Message-----
> From: Paul C. Bryan [mailto:email@pbryan.net]
> Sent: 03 January 2002 20:12
> To: Jakarta Commons Developers List
> Subject: Re: [HttpClient] Support for Basic and Form-based
authentication
> ?
> 
> Vincent Massol wrote:
> 
> > I'd like to know if HttpClient currently supports any authentication
> > scheme (basic, form-based) ? If not, is someone working on this ? If
no,
> > do you think it would be good to add it ?
> 
> 
> The HttpClient library currently supports HTTP basic authentication.
> 
> As there are no standards for form-based authentication
(acknowledgement
> of success, failure, state mechanisms, and so on), it is up to the
> application to implement site-specific form-based authentication
schemes.

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 ?

Examples attached (provided by Jason).

Thanks
-Vincent

> 
> > The end story is that I need to add basic and form-authentication to
> > Cactus (We actually have the code for it as Jason Robertson has
> > submitted it on the Cactus mailing-list) but I also wanted to move
the
> > HTTP connection to HttpClient (instead of using HttpURLConnection
and my
> > own code on top of it). Of course, I would prefer not to reinvent
the
> > wheel and have a clean separation of concerns, which is why I am
asking
> > this here: Do you think authentication is too application-centric
for
> > HttpClient or do you think it is in scope ?
> 
> 
> IMHO, I think form-based authentication is too application-centric for
> HttpClient, therefore out of scope. However, HTTP authentication is in
> HttpClient, right where it belongs.
> 
> 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>
> 


Mime
View raw message