I think encoding an absolute url and then re-relativize them, seems like a good idea. We do need 'full'-relative urls, because otherwise rewriting proxies will break.
Emond On Monday 27 August 2012 13:50:05 Martin Grigorov wrote: > Hi, > > I think I found a solution for this problem > (https://issues.apache.org/jira/browse/WICKET-4645 / > https://issues.apache.org/bugzilla/show_bug.cgi?id=53469) : > > org.apache.wicket.protocol.http.servlet.ServletWebResponse.java: > > @Override > public String encodeURL(CharSequence url) > { > Args.notNull(url, "url"); > > UrlRenderer urlRenderer = RequestCycle.get().getUrlRenderer(); > Url _url = Url.parse(url); > String fullUrl = urlRenderer.renderFullUrl(_url); > String encodedFullUrl = httpServletResponse.encodeURL(fullUrl); > Url _encoded = Url.parse(encodedFullUrl); > String encodedRelativeUrl = > urlRenderer.renderRelativeUrl(_encoded); > return encodedRelativeUrl; > } > > I.e. now Wicket makes the url absolute, pass it to the container for > encoding and then Wicket makes it relative again. > The only thing that bothers me is that "relative" in the previous > sentence is not really relative. > The produced urls look like: > "/contextPath/filterPath/a/b;jsessionid=qwerty?someParam=value" > As you see this is much longer than > "../../a/b;jsessionid=qwerty?someParam=value" in the case when the > context path is not ROOT and the filter path is not "/*". > Should I try to re-relativize it again by improving > org.apache.wicket.request.UrlRenderer#renderRelativeUrl() or this is > good enough ? > > On Sat, Jul 28, 2012 at 2:01 AM, Mark Thomas <[email protected]> wrote: > > On 27/07/2012 09:10, Martin Grigorov wrote: > >> On Fri, Jul 27, 2012 at 3:24 AM, Pedro Henrique Oliveira dos Santos > >> > >> <[email protected]> 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
