On 07/08/12 22:33, bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53584
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #1 from Mark Thomas <ma...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
