On 27/07/2012 09:10, Martin Grigorov wrote: > On Fri, Jul 27, 2012 at 3:24 AM, Pedro Henrique Oliveira dos Santos > <pedros...@gmail.com> wrote: >> Hi Martin, >> >> I don't see how to wrap the request or the response can be useful >> here. Even if we decorate the container request to return its URI >> based on the page being rendered address it will not be enough >> because Servlet API does not allow us to change the composition of >> a response. i.e. we are not able to set on which request URI the >> encode method of the response will work on (Tomcat API allows such >> thing but I'd rather not use to it).
My bad. I was thinking of using some methods that were added early in the Servlet 3.0 development cycle that were later removed. Wrapping isn't going to help here unless Wicket implements its own encode methods in the wrapper (which instinctively I don't like as a solution). >> I simply don't get why Tomcat added such validation in the encode >> method. The validation (that any URL must part of the web application for the session ID to be added) has been present as far back as I can remember. That it didn't work correctly for relative URLs was a bug that only recently surfaced. In short, Tomcat should not be exposing the session ID to URLs outside of the web application. > The new problem is that Tomcat uses the normalization even in > #encodeURL(), this method just encodes jsessionid if needed, even > for relative urls. To decide whether the relative url is part of the > current application Tomcat makes the url absolute and normalizes it. > When Wicket starts rendering the rendering for PageB (from my first > mail) it produces relative urls to PageB, but later Tomcat > normalizes them against PageA and url like > 'http://www.example.com/a/b/../../../../c/d.html' fails because > there are too many '..'s. > > I hope the problem is more clear now. > >> >> It looks like the response will not encode the session id to links >> and callbacks in the buffered pages in a deeper path from Tomcat >> 7.0.29 on. I'm OK with the way the Tomcat team worked around this >> issue. Who knows if they aren't only doing some good by preventing >> some session fixation attacks. > > They didn't workaround it yet. For now we discuss possible solutions > for the next version. At the moment, I don't see a way for Tomcat to: - retain the check that a URL is part of the web application before adding the session ID; and - correctly support the passing of relative URLs to encodeURL() that are relative to something other than the currently processing request. I am open to suggestions. On a separate note, I intend to request some clarification on the handling of relative URLs and encodeURL() from the EG. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
