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
