ICEfaces
  1. ICEfaces
  2. ICE-8206

User Session Expired dialog shown continuously in a Liferay Portlet

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-1.8.2.GA_P04
          • Fix Version/s: EE-1.8.2.GA_P04
          • Component/s: Bridge, Framework
          • Labels:
            None
          • Environment:
            Liferay 5.2.3 - Tomcat 6.0.18 / Liferay 6.1.0 - Tomcat 7.0.23

            Description

            Once the User Session Expire dialog is shown in a Liferay portlet, clicking the Reload button reloads the page. Upon reload of the page the User Session Expired popup is shown once again. This continues until the browser is closed and re-opened.

             

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Arran Mccullough added a comment -

              Attached out sample chat portlet that can reproduce the issue. Session timeout has been set to 3 min. No change in behavior if the tomcat server session timeout is set to 3 min, other then the liferay client side notification showing after 1 min.

              This sample was build with the ICEfaces EE 1.8.2 P04 jars.

              Show
              Arran Mccullough added a comment - Attached out sample chat portlet that can reproduce the issue. Session timeout has been set to 3 min. No change in behavior if the tomcat server session timeout is set to 3 min, other then the liferay client side notification showing after 1 min. This sample was build with the ICEfaces EE 1.8.2 P04 jars.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Looks to be a session cookie mixup. The original session cookie path is root ( "/" ) which is fine until the session expires and the first request made to /chat/block/receive-updated-views decides that the new cookie should be stored under the app context path ( "/chat" ). It's a bit complicated because Ajax requests in 1.8 don't go through the portal container which by default is the root context in Tomcat.

              In any event, you can tell Tomcat to avoid this by changing a configuration setting. As per http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html:

              emptySessionPath: If set to true, all paths for session cookies will be set to /. This can be useful for portlet specification implementations. If not specified, this attribute is set to false.

              So for Tomcat you do the following:

              1) Edit the file [tomcat]/conf/server.xml
              2) Add the emptySessionPath attribute to the Connector. For example:

              <Connector port="8080" protocol="HTTP/1.1"
              connectionTimeout="20000"
              redirectPort="8443" URIEncoding="UTF-8" emptySessionPath="true"/>

              3) Restart Tomcat for the change to be picked up.

              I was able to reload reliably after that.

              For Glassfish I believe you edit as per http://java.net/jira/browse/PORTLET_CONTAINER-170:

              "The workaround is to add the following entry to sun-web.xml of the
              portletdriver.war before </sun-web-app> and then redeploy the war."

              <session-config>
              <cookie-properties>
              <property name="cookiePath" value="/" />
              </cookie-properties>
              </session-config>

              I also found a Liferay forum where they were recommending the same setting for Glassfish + Liferay when running in a cluster (without ICEfaces) so it may be the best thing to do regardless:

              http://www.liferay.com/community/forums/-/message_boards/message/1006468

              Show
              Deryk Sinotte added a comment - Looks to be a session cookie mixup. The original session cookie path is root ( "/" ) which is fine until the session expires and the first request made to /chat/block/receive-updated-views decides that the new cookie should be stored under the app context path ( "/chat" ). It's a bit complicated because Ajax requests in 1.8 don't go through the portal container which by default is the root context in Tomcat. In any event, you can tell Tomcat to avoid this by changing a configuration setting. As per http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html: emptySessionPath: If set to true, all paths for session cookies will be set to /. This can be useful for portlet specification implementations. If not specified, this attribute is set to false. So for Tomcat you do the following: 1) Edit the file [tomcat] /conf/server.xml 2) Add the emptySessionPath attribute to the Connector. For example: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" emptySessionPath="true"/> 3) Restart Tomcat for the change to be picked up. I was able to reload reliably after that. For Glassfish I believe you edit as per http://java.net/jira/browse/PORTLET_CONTAINER-170: "The workaround is to add the following entry to sun-web.xml of the portletdriver.war before </sun-web-app> and then redeploy the war." <session-config> <cookie-properties> <property name="cookiePath" value="/" /> </cookie-properties> </session-config> I also found a Liferay forum where they were recommending the same setting for Glassfish + Liferay when running in a cluster (without ICEfaces) so it may be the best thing to do regardless: http://www.liferay.com/community/forums/-/message_boards/message/1006468
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Resolving as fixed as the configuration change should do the trick.

              Show
              Deryk Sinotte added a comment - Resolving as fixed as the configuration change should do the trick.

                People

                • Assignee:
                  Deryk Sinotte
                  Reporter:
                  Arran Mccullough
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: