hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralf Pöhlmann (JIRA) <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1186) NTLM authenticated connections are mixed
Date Tue, 24 Apr 2012 13:01:34 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260498#comment-13260498

Ralf Pöhlmann commented on HTTPCLIENT-1186:

Thanks for your quick response, I will try to elaborate on the problem.

The problem occurs when using NTLM authentication with multiple threads and a shared connection

One thread sends a request and authenticates a connection from the connection pool. Then another
thread (same user) makes a request and reuses the connection from the first thread. While
the second thread is still working the first one tries to send another request. As the connection
is still in use by the second thread, the first one will get a new connection from the pool.
This newly created connection will get authenticated but the usertoken will not be set on
that connection. As a consequence you have a connection in your pool which is authenticated
but not marked with a user token. This is a potential security risk and also a problem if
the connection is reused by a request from another user.

Have a look at the execute() method from the DefaultRequestDirector. In my opinion the userToken
should be set whenever you have a managed connection as the connection pool might have returned
a new connection for that usertoken:

Basically it should look like this:
if (managedConn != null) {
    if (userToken == null) {
        userToken = userTokenHandler.getUserToken(context);
        context.setAttribute(ClientContext.USER_TOKEN, userToken);
    if (userToken != null) {
> NTLM authenticated connections are mixed
> ----------------------------------------
>                 Key: HTTPCLIENT-1186
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1186
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.1.3
>            Reporter: Ralf Pöhlmann
>            Priority: Critical
>              Labels: DefaultRequestDirector
> Executing multiple request using the same http context as recommended mixes authenticated
connections among different users. 
> 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 connection 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 = context.getAttribute(ClientContext.USER_TOKEN);
> ...
> if (managedConn != null && userToken == null) {
>    userToken = userTokenHandler.getUserToken(context);
>    context.setAttribute(ClientContext.USER_TOKEN, userToken);
>    if (userToken != null) {
>       managedConn.setState(userToken);
>    }
> }
> and RouteSpecificPool:
>     public BasicPoolEntry allocEntry(final Object state) {
>         if (!freeEntries.isEmpty()) {
>             ListIterator<BasicPoolEntry> it = freeEntries.listIterator(freeEntries.size());
>             while (it.hasPrevious()) {
>                 BasicPoolEntry entry = it.previous();
>                 if (entry.getState() == null || LangUtils.equals(state, entry.getState()))
>                     it.remove();
>                     return entry;
>                 }

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

View raw message