tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <br...@pingtoo.com>
Subject Re: [Bug 53584] Forms authentication without cookies requires double submission in 6.0.33
Date Tue, 14 Aug 2012 13:08:27 GMT
On 07/08/12 22:33, bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53584
>
> Mark Thomas <markt@apache.org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   OS|                            |All
>
> --- Comment #1 from Mark Thomas <markt@apache.org> ---
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message