On Mon, Aug 27, 2012 at 2:54 PM, Emond Papegaaij <[email protected]> wrote: > 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.
I'm working on this. But I still have problems with Url.isAbsolute() that returns 'true' for 'http://host:9090/something' and just '/something'. > > 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
