Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Tue, 24 Apr 2012 13:35:35 +0000 (UTC)
From: "Oleg Kalnichevski (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: 
 <1618764505.9529.1335274535460.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1914831546.6393.1335211833883.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HTTPCLIENT-1186) NTLM authenticated connections
 are mixed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D13260544#comment-13260544 ]=20

Oleg Kalnichevski commented on HTTPCLIENT-1186:
-----------------------------------------------

I am sorry but I still fail to see a security issue here. Before a connecti=
on gets released back to the manager (and therefore before it can be potent=
ially leased to another user) its state will be updated. It really does not=
 matter if a connection starts its life as stateless. What matters is wheth=
er or not it is stateful by the time it gets released back to the pool.

Could you please provide a test case that demonstrates how an authenticatio=
n connection can be leased to a user with a different security context?=20

Oleg
               =20
> NTLM authenticated connections are mixed
> ----------------------------------------
>
>                 Key: HTTPCLIENT-1186
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-118=
6
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.1.3
>            Reporter: Ralf P=C3=B6hlmann
>            Priority: Critical
>              Labels: DefaultRequestDirector
>
> Executing multiple request using the same http context as recommended mix=
es authenticated connections among different users.=20
> If we execute two request usign the same context, the first request adds =
the user token to the http context as well as to the connection properties.=
 The second request fins already a user token in the http context but if a =
new connection will be created (no free connection in the pool) this new co=
nnection is never assigned to an user token and is used independent of any =
user context!
> see DefaultRequestDirector:
> // See if we have a user token bound to the execution context
> Object userToken =3D context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn !=3D null && userToken =3D=3D null) {
>    userToken =3D userTokenHandler.getUserToken(context);
>    context.setAttribute(ClientContext.USER_TOKEN, userToken);
>    if (userToken !=3D null) {
>       managedConn.setState(userToken);
>    }
> }
> and RouteSpecificPool:
>     public BasicPoolEntry allocEntry(final Object state) {
>         if (!freeEntries.isEmpty()) {
>             ListIterator<BasicPoolEntry> it =3D freeEntries.listIterator(=
freeEntries.size());
>             while (it.hasPrevious()) {
>                 BasicPoolEntry entry =3D it.previous();
>                 if (entry.getState() =3D=3D null || LangUtils.equals(stat=
e, entry.getState())) {
>                     it.remove();
>                     return entry;
>                 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira

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