On 14/08/12 16:58, Mark Thomas wrote:
Brian Burch <br...@pingtoo.com> wrote:
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
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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
