You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2013/05/27 15:43:20 UTC

[jira] [Resolved] (WICKET-5202) Page redirects can fail when using url encoding

     [ https://issues.apache.org/jira/browse/WICKET-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-5202.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.5.11
                   7.0.0
                   6.9.0
    
> Page redirects can fail when using url encoding
> -----------------------------------------------
>
>                 Key: WICKET-5202
>                 URL: https://issues.apache.org/jira/browse/WICKET-5202
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.8.0
>         Environment: Linux, Tomcat 7.0.39, JDK 1.7.0
>            Reporter: James Gifford
>            Assignee: Martin Grigorov
>             Fix For: 6.9.0, 7.0.0, 1.5.11
>
>         Attachments: jira5202.tgz
>
>
> When url encoding is used instead of cookies for session management, some redirections do not work in Wicket 6.8.0. The problem appears to be in UrlRenderer.renderRelativeUrl, which returns the (invalid) relative URL:
> "..//demo/app;jsessionid=0BFE4703434CFF7BEBAE5CBF6C60B15F" 
> when passed the URL:
> "http://localhost:8080/demo/app;jsessionid=0BFE4703434CFF7BEBAE5CBF6C60B15F"
> and when the UrlRenderer's base URL is: 
> "wicket/page?1-1.ILinkListener-link"
> This is because the removeCommonPrefixes method tries to compare segments between the encoded target URL and a URL parsed from 
> (URLRenderer line 319):
> Url commonPrefix = Url.parse(request.getContextPath() + request.getFilterPath());
> This second URL does not contain the ;jsessionid=... suffix and the removeCommonPrefixes method doesn't remove prefixes properly. The problem doesn't occur when using cookies for session management, of course.
> This issue is new between Wicket version 6.2.0 and 6.8.0. When deployed into a servlet container using url-encoding for session management, the following app works under Wicket 6.2.0 but fails (because of redirecting to an invalid URL) under Wicket 6.8.0:
> // ------------------------
> // App.java
> import org.apache.wicket.protocol.http.WebApplication;
> import org.apache.wicket.Page;
> public class App extends WebApplication {
>     @Override
>     public Class<? extends Page> getHomePage() {
>         return A.class;
>     }
> }
> // ------------------------
> // A.java
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.markup.html.link.Link;
> public class A extends WebPage {
>     public A() {
>         add(new Link<Object>("link") {
>             @Override
>             public void onClick() {
>                 setResponsePage(B.class);
>             }
>         });
>     }
> }
>     
> // ------------------------
> // B.java
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.markup.html.link.Link;
> public class B extends WebPage {
>     public B() {
>         add(new Link<Object>("link") {
>             @Override
>             public void onClick() {
>                 setResponsePage(A.class);
>             }
>         });
>     }
> }
> // ------------------------
> Clicking the link on the home page A will successfully navigate to page B. Clicking the link on page B should navigate to page A. Under Wicket 6.2.0, or Wicket 6.8.0 with cookies, it works. With Wicket 6.8.0 and url-encoding, it tries to redirect to an incorrect URL like 
> http://localhost:8080/demo/app//demo/app;jsessionid=0BFE4703434CFF7BEBAE5CBF6C60B15F
> which fails (note the double slash and repeated context/filter in the URL). 
> It is possible to configure Tomcat to use url encoding instead of cookies for session management by editing the conf/context.xml file within the Tomcat installation and making the root element of that file read:
>  <Context cookies="false">

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira