tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: [Bug 53584] Forms authentication without cookies requires double submission in 6.0.33
Date Tue, 14 Aug 2012 17:42:23 GMT
On 14/08/12 16:58, Mark Thomas wrote:
> Brian Burch <> wrote:
>> On 07/08/12 22:33, wrote:
>>> Mark Thomas <> changed:
>>>              What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>>                    OS|                            |All
>>> --- Comment #1 from Mark Thomas <> ---
>>> Thanks for an excellent bug report. The issue was a real pleasure to
>>> investigate - not just because the root cause was interesting but
>> because I
>>> could focus on the interesting bits rather than having to waste time
>> trying to
>>> build the test WAR using the current flavour of the month for scm
>> and/or build
>>> tool and/or source layout. Simple WARs are *SO* much easier to work
>> with.
>>> The clear steps to re-create the issue were also extremely helpful.
>> So again,
>>> thank-you.
>>> The root cause is that as of 6.0.33 path parameters are included the
>> value
>>> returned from HttpServletRequest.getRequestURI(). During the FORM
>> auth, one of
>>> the checks post authentication is "Does the current URI equal the
>> original
>>> URI?" The problem is that the current URI always contains the session
>> ID as a
>>> path parameter whereas the first time through the authentication the
>> original
>>> URI does not.
>>> This issue also affects trunk and 7.0.x.
>>> I have fixed this issue in trunk and 7.0.x for 7.0.30 onwards and
>> proposed the
>>> fix for 6.0.x.
>> Mark,
>> I have intermittently observed a similar problem with tc6 and tc7 over
>> the last couple of years. It has been on my own list of things to
>> investigate, but so far my various efforts haven't allowed me to
>> reproduce it on demand and analyse it fully.
>> Bug 53584 deals with the case where the session id is not transmitted
>> in
>> a cookie, but my situation does use cookies. Reading about your
>> investigation and solution suggests to me that the underlying problem
>> is
>> not directly related to the "no cookie" case, but you mention a
>> mismatch
>> in the uri as the underlying cause. I feel it is possible that my own
>> case also involves a uri mismatch, but I need to understand this
>> particular bug and its fix before I can decide.
>> Even though it is fixed, I would like to write a unit test case for
>> this
>> particular bug. Once done, I can use it as a template to simulate my
>> own
>> situation and see whether that has been fixed too.
>> I would like to start developing the first test soon, but you could
>> save
>> me some time. Based on your current understanding, would you mind
>> outlining the minimal conditions needed to trigger this particular
>> failure case?
>> Thanks,
>> Brian
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> Steps to reproduce are provided in the bug report. The root cause was that the redirect
after authentication contained a path parameter (the session id) which was not present in
the saved request hence the URIs did not match.
> I don't see any way this could occur when cookies are used unless something in the request
path is injecting path parameters into the URI.

Thanks for your opinions. I'll get on with the new test - it will be 
useful to avoid regression. (I extrapolate from your comment that my own 
problem might turn out to be an error in the configuration or user code).

> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message