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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
