[
https://issues.apache.org/jira/browse/TS-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061427#comment-15061427
]
Aaron McClimont commented on TS-3866:
-------------------------------------
Leif,
I'm not able to provide a test setup for you to test against, however, I can
attempt to provide additional debug information for you.
Based on the private.diff attachment on the related issue TS-1491, I have
been able to determine that the HttpSM.cc code between branch 4.1 (which
worked) and 5.3 (which doesn't work) remain largely intact, however there have
been a few changes:
* The configuration setting "proxy.config.http.auth_server_session_private" has
been introduced
* The flag "will_be_private_ss" has been introduced
* The check for the authorization header has been relocated such that it is
executed earlier. This apparently allows for 'not wasting a connection from
the pool if we already know that the session will be private', as well as
allowing for the private session being overridable by a plugin later.
There has also been additional debugging enabled under tag "http_ss_auth",
which provides the following output:
{code}
# Request 1: (No authenticate headers)
[Dec 16 19:39:31.117] Server {0x2ba930100700} DEBUG: (http_ss) [44] session
born, netvc 0x2ba944013a00
[Dec 16 19:39:31.117] Server {0x2ba930100700} DEBUG: (http_ss) Releasing
session, private_session=0, sharing_match=1
[Dec 16 19:39:31.120] Server {0x2ba930100700} DEBUG: (http_ss) [44] [release
session] session placed into shared pool
# Request 2: (Authenticate headers)
[Dec 16 19:39:34.881] Server {0x2ba9328f7700} DEBUG: (http_ss_auth) Setting
server session to private for authorization header
[Dec 16 19:39:34.881] Server {0x2ba930201700} DEBUG: (http_ss) [45] session
born, netvc 0x2ba944013740
[Dec 16 19:39:34.881] Server {0x2ba930201700} DEBUG: (http_ss) Setting server
session to private
[Dec 16 19:39:34.883] Server {0x2ba930201700} DEBUG: (http_ss) Releasing
session, private_session=1, sharing_match=1
[Dec 16 19:39:34.883] Server {0x2ba930201700} DEBUG: (http_ss) [45] session
closing, netvc 0x2ba944013740
# Request 3: (Authenticate headers)
[Dec 16 19:39:34.894] Server {0x2ba9328f7700} DEBUG: (http_ss_auth) Setting
server session to private for authorization header
[Dec 16 19:39:34.894] Server {0x2ba92b925540} DEBUG: (http_ss) [46] session
born, netvc 0x2ba944013480
[Dec 16 19:39:34.894] Server {0x2ba92b925540} DEBUG: (http_ss) Setting server
session to private
[Dec 16 19:39:34.897] Server {0x2ba92b925540} DEBUG: (http_ss) Releasing
session, private_session=1, sharing_match=1
[Dec 16 19:39:34.898] Server {0x2ba92b925540} DEBUG: (http_ss) [46] session
closing, netvc 0x2ba944013480
{code}
According to the above debug output, the authorization header is being
detected, and a private session is being created.
I will attempt to locate the change that rearranged the authentication
headers check, and revert this change in my local source. This will be to see
if it was the cause of the regression.
Kind regards,
Aaron.
> Browser always prompts for authentication (NTLM) - Regression?
> --------------------------------------------------------------
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
> Reporter: Aaron McClimont
> Priority: Critical
> Labels: Regression
> Fix For: 6.2.0
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
