Jetty

Redirecting using a jsf action removes the jsessionid

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 6.1.18, 6.1.19, 6.1.20, 6.1.21
  • Fix Version/s: 7.4.2
  • Component/s: Servlet
  • Labels:
    None
  • Environment:
  • Number of attachments :
    0

Description

Redirecting using a jsf action removes the "jsessionid"-GET-parameter:

Steps to reproduce:
a) start the web-app using mvn jetty:run
b) navigate to the page "redirectSrc.jsf"
c) Click on one of the links on the page (a redirect will happen)

Actual:
-> the "redirectDest.jsf" opens in a new tab, but NO jsessionid is appended to the URL
Expected:
-> the "redirectDest.jsf" opens in a new tab, and the jsessionid is appended to the URL

Note: It works on Tomcat 6.0.14 with cookies=false.

----------------
pom.xml

<plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
        <version>${maven.jetty.plugin.version}</version>
        <configuration>
          <scanIntervalSeconds>0</scanIntervalSeconds>
          <webDefaultXml>src/jetty/resources/jetty-webdefault.xml</webDefaultXml>
          <overrideWebXml>src/jetty/resources/development-overrides-web.xml</overrideWebXml>
          <scanTargetPatterns>
            <scanTargetPattern>
              <directory>src/main/webapp/</directory>
              <excludes>
                <exclude>**/*.xhtml</exclude>
                <exclude>**/*.html</exclude>
                <exclude>**/*.css</exclude>
                <exclude>**/*.js</exclude>
              </excludes>
              <includes>
                <include>**/*.properties</include>
                <include>**/*.xml</include>
              </includes>
            </scanTargetPattern>
          </scanTargetPatterns>
          <connectors>
            <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
              <port>${jetty.port}</port>
              <host>localhost</host>
              <maxIdleTime>60000</maxIdleTime>
            </connector>
          </connectors>
          <stopPort>${jetty.stopport}</stopPort>
          <stopKey>foo</stopKey>
        </configuration>
      </plugin>

Navigation-rule:

<from-view-id>/pages/main/redirectSrc.xhtml</from-view-id>
    <navigation-case>
      <from-outcome>redirectDest</from-outcome>
      <to-view-id>/pages/main/redirectDest.xhtml</to-view-id>
      <redirect />
    </navigation-case>

redirectSrc.xhtml

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
                xmlns:ui="http://java.sun.com/jsf/facelets"
                xmlns:h="http://java.sun.com/jsf/html"
                xmlns:f="http://java.sun.com/jsf/core"
                xmlns:a4j="http://richfaces.org/a4j"
                xmlns:rich="http://richfaces.org/rich"
                xmlns:c="http://java.sun.com/jstl/core"
                >
  <fieldset>
    <legend>
    h:form with h:commandLink+targets and redirecting jsf action 
    </legend>
    <ul>
    <li><span style="color: green;">[works]</span> Tomcat 6.0.14</li>
    <li><span style="color: red;">[fails]</span> Jetty 6.1.18</li>
    <li><span style="color: red;">[fails]</span> Jetty 6.1.19</li>
    <li><span style="color: red;">[fails]</span> Jetty 6.1.20</li>
    <li><span style="color: red;">[fails]</span> Jetty 6.1.21</li>
    </ul>
    
    Steps to reproduce:
    <ol>
    <li>Click on a link below</li>
    <li>Check, whether a new site was opened in a new tab and it uses the jsessionid in the url.</li>
    </ol> 
    <h:form>
        <h:commandLink  
                           action="redirectDest" 
                           value="redirect (target @ h:commandlink)"
                           target="_blank"
                           />
    </h:form>
    <h:form target="_blank">
        <h:commandLink  
                           action="redirectDest" 
                           value="redirect (target @ h:form)"
                           />
    </h:form>
    <h:form target="_blank">
        <h:commandLink  
                           action="redirectDest" 
                           value="redirect (target @ h:form+h:commandLink)"
                           target="_blank"
                           />
    </h:form>
    </fieldset>

</ui:composition>

redirectDest.xhtml

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
                xmlns:ui="http://java.sun.com/jsf/facelets"
                xmlns:h="http://java.sun.com/jsf/html"
                xmlns:f="http://java.sun.com/jsf/core"
                xmlns:a4j="http://richfaces.org/a4j"
                xmlns:rich="http://richfaces.org/rich"
                xmlns:c="http://java.sun.com/jstl/core"
                >
Has to be opened in a new tab and has to use the jsessionid in the url.

</ui:composition>

Activity

Hide
Benno Markiewicz added a comment -
Show
Benno Markiewicz added a comment - Found a similar issue http://issues.apache.org/jira/browse/GERONIMO-2192
Hide
Jan Bartel added a comment -

Hi Benno,

Could you please turn on debug and capture the jetty log?

Jetty's redirect mechanism seems to be working - if you use the test webapp that comes with the distro, you'll see there is a DispatcherServlet in there. You can use it to get the server-side to perform redirects. So, first turn off cookies for localhost, then click on the Session Dump Servlet link and create a session. You should see the jsessionid in the url.
Now, try some forwards like like so:

http://localhost:8080/dispatch/forward/hello;jsessionid=6cwwk1op5n4s

http://localhost:8080/dispatch/forward/session;jsessionid=6cwwk1op5n4s

On the session page, you should see a link entitled "Encoded Link". You should see the jsessionid on the link, even after the forward.

If there's extra debugging that you can enable for JSF, that would be good too, as I'd be interested to see exactly what kind of redirects are being done.

thanks
Jan

Show
Jan Bartel added a comment - Hi Benno, Could you please turn on debug and capture the jetty log? Jetty's redirect mechanism seems to be working - if you use the test webapp that comes with the distro, you'll see there is a DispatcherServlet in there. You can use it to get the server-side to perform redirects. So, first turn off cookies for localhost, then click on the Session Dump Servlet link and create a session. You should see the jsessionid in the url. Now, try some forwards like like so: http://localhost:8080/dispatch/forward/hello;jsessionid=6cwwk1op5n4s http://localhost:8080/dispatch/forward/session;jsessionid=6cwwk1op5n4s On the session page, you should see a link entitled "Encoded Link". You should see the jsessionid on the link, even after the forward. If there's extra debugging that you can enable for JSF, that would be good too, as I'd be interested to see exactly what kind of redirects are being done. thanks Jan
Hide
Jan Bartel added a comment -

Benno,

I had a closer read of your initial report, and I also tested doing serverside ServletResponse.sendRedirect() instead of the forwarding.
If I call response.sendRedirect(response.encodeRedirectURL("/hello"))) after creating a session, the jsessionid is certainly appended to the URL.
I'm going to need some more info from you in the form of logs or stack traces to get much further with this one.

thanks,
Jan

Show
Jan Bartel added a comment - Benno, I had a closer read of your initial report, and I also tested doing serverside ServletResponse.sendRedirect() instead of the forwarding. If I call response.sendRedirect(response.encodeRedirectURL("/hello"))) after creating a session, the jsessionid is certainly appended to the URL. I'm going to need some more info from you in the form of logs or stack traces to get much further with this one. thanks, Jan
Hide
Benno Markiewicz added a comment -

How do i enable debugging of jetty?

<category name="org.mortbay">
<priority value="trace" />
</category>

I tried the following, but it pollutes the console...

  • mvn test-compile jetty:run -DDEBUG
Show
Benno Markiewicz added a comment - How do i enable debugging of jetty? <category name="org.mortbay"> <priority value="trace" /> </category> I tried the following, but it pollutes the console...
  • mvn test-compile jetty:run -DDEBUG
Hide
Jan Bartel added a comment -

Benno,

http://docs.codehaus.org/display/JETTY/Debugging

Defining the DEBUG system property is correct. The default logger logs to stderr.

cheers
Jan

Show
Jan Bartel added a comment - Benno, http://docs.codehaus.org/display/JETTY/Debugging Defining the DEBUG system property is correct. The default logger logs to stderr. cheers Jan
Hide
Jan Bartel added a comment -

Benno,

Any progress on this one?

Jan

Show
Jan Bartel added a comment - Benno, Any progress on this one? Jan
Hide
Till Wenzinger added a comment -

I analyzed a similar problem in Jetty 6.1.21/26 and 7.2.0. According to my
tests, a possible fix is to encode the URL in org.eclipse.jetty.server.Response#sendRedirect(String), case "!canonical.equals(path)" by adding "location=encodeRedirectURL(location);" after "location=buf.toString();" (line 439 in Jetty 7.2.0).

Show
Till Wenzinger added a comment - I analyzed a similar problem in Jetty 6.1.21/26 and 7.2.0. According to my tests, a possible fix is to encode the URL in org.eclipse.jetty.server.Response#sendRedirect(String), case "!canonical.equals(path)" by adding "location=encodeRedirectURL(location);" after "location=buf.toString();" (line 439 in Jetty 7.2.0).
Hide
Jan Bartel added a comment -

Greg,
Can you evaluate the suggested workaround?
thanks
Jan

Show
Jan Bartel added a comment - Greg, Can you evaluate the suggested workaround? thanks Jan
Hide
Greg Wilkins added a comment -

Wow this one really fell through the cracks! sorry it took so long to fix.

sendRedirect now calls encodeRedirectURL

Show
Greg Wilkins added a comment - Wow this one really fell through the cracks! sorry it took so long to fix. sendRedirect now calls encodeRedirectURL

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: