Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-133668

There are no log traces in case the extend session cannot extend the user session


    The extend session functionality is based in following portal properties:


    These properties are not too obvious for our customers:

    • Out of the box, the behaviour is to only auto-extend the guest users before the session times out, but it can be enabled for every user setting session.timeout.auto.extend to true.
    • Note that the guest user sessions are extended even this property is set to false
    • The session.timeout.auto.extend.offset controls the number of seconds the /c/portal/extend_session request will be executed before the session is timed out. If this value is too close to zero, in case there is any network delay or any problem related to this request, it will reach the Liferay server when the session is already expired and it won't be extended.
    • There is also a common misunderstanding between our customers with the session.timeout property. It doesn't control the session timeout:
      • The session timeout must be set in the application server configuration (for example web.xml file of Tomcat file)
      • Liferay cannot get this value from the application server configuration, so the session.timeout purpose is to communicate to Liferay application the value you have set in the application server level.

    The customers that set a wrong configuration in these session.timeout properties won't be aware of this issue unless they manually test it, as the session length is usually 30 minutes, it is difficult to test and link with the unespected behaviors and wrong traces.
    A wrong configuration for example can cause the following warn traces:

    User 0 is not allowed to access URL http://localhost:8080/ and portlet com_liferay_login_web_portlet_LoginPortlet: User 0 did not provide a valid CSRF token for com.liferay.portlet.SecurityPortletContainerWrapper

    (see LPS-75442, LPS-83881 or LRDOCS-6364)

    In order to make easier to configure this settings, we must add some warn traces in the extend_session requests in case they are not able to extend the session. This can be easily implemented adding in the extend_session.jsp a check that compares the incoming and the effective session ids and write a warn trace in case the received session id is not the current one.

    Steps to reproduce

    1. Configure in the Tomcat application server the session timeout to 2 minutes in the ROOT/WEB-INF/web.xml file
    2. Set in the portal-ext.properties the property: session.timeout=5 (this is a wrong configuration as it is greater than the Tomcat one, but we want to test this use case)
    3. Set in the portal-ext.properties the property: session.timeout.auto.extend=true
    4. Start the Liferay server
    5. Login with any user
    6. Wait more than 5 minutes
    7. Check the log file:
      • Expected behavior: a warning trace is written to the log file as the extend_session request was done after the session timed out.
      • Wrong behavior: no warning trace is written to the log file when the extend_session request is done after the session time out.


        Issue Links



            marcell.weller Marcell Weller
            jorge.diaz Jorge Diaz
            Participants of an Issue:
            Recent user:
            Jorge Diaz
            Engineering Assignee:
            Jorge Diaz
            0 Vote for this issue
            1 Start watching this issue


              Days since last comment:
              1 year, 9 weeks, 2 days ago


                Version Package
                7.0.0 DXP FP102
       DXP SP17
                7.1.10 DXP FP25
                7.2.10 DXP FP15
       DXP SP3
                7.4.1 CE GA2 DXP 7,4
                7.4.13 DXP GA1