Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <46C6C57E.3010306@dubioso.net>
Date: Sat, 18 Aug 2007 12:10:06 +0200
From: Roland Weber <ossfwot@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.6) Gecko/20070807 SeaMonkey/1.1.4
MIME-Version: 1.0
To: HttpComponents Project <httpcomponents-dev@jakarta.apache.org>
Subject: Re: Apache httpclient with NTLM
References: 
 <DA63C6E8B207E748B20D46DFED7B772D045538B3@dhost002-45.dex002.intermedia.net>
In-Reply-To: 
 <DA63C6E8B207E748B20D46DFED7B772D045538B3@dhost002-45.dex002.intermedia.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Roei Erez wrote:
> I would like to get involved in implementing this feature.

That is very welcome!

> I have read the 'ConnectionManagementDesign' in the wiki,
> and want to come up with a good and clean design for this issue

That is even more welcome :-)

At the time I collected my thoughts in the Wiki, I was
still considering to add some kind of auth state to the
route itself. That is no longer the case. I'll have to
read through the page soon, and maybe update it.

I see two different aspects to connection authentication.
First, there is the authentication state as seen by
HttpAuth, where you would for example store some random
challenge or such stuff. That state needs to be updated
while the connection is used, and has to be available
when the connection is re-used.
Second, there is the authentication level/info/whatever
as seen by the connection manager. That is information
needed to decide on connection re-use in the presence
of authentication state. My view on this is as follows:

When allocating a connection, the application passes
an object that represents the available credentials.
Something like "I can authenticate to the proxy as
XYZ and to the server as VWQ". The connection manager
can then return a closed or unauthenticated connection,
or one that is proxy-authed as XYZ, or one that is
server-authed as VWQ, or one that has both auths.
But the connection manager must not return a connection
that is proxy-authed as something else than XYZ, or one
that is server-authed as something else than VWQ.
If no such object is passed, only connections without
authentication can be re-used. To keep this stuff
manageable, I thought about something like:

interface ConnAuthLevel { // or ConnAuthInfo or whatever
  boolean isUpgradeableTo(ConnAuthInfo);
  boolean isReachableFrom(ConnAuthInfo);
}

Two methods are needed so that both objects, the
one passed by the application and the one stored
with the connection, can disallow the re-use.
A default implementation of the interface would
simply wrap an object or null, allowing upgrade
from null but otherwise requiring the same object
in order to allow re-use.

I would like to keep HttpConn and HttpAuth independent
of eachother, hence the separate AuthState in HttpAuth
and ConnAuthLevel in HttpConn. That could be tied
together in a module-auth-ntlm which depends on both.

Thoughts, suggestions, questions are welcome.

cheers,
  Roland


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