How does session-cookie max-age in standalone.xml work with session-timeout in web.xml?

[milspec]

Hi all,

This may be an undertow question or a more general "java webapp question"...

How does session-cookie max-age in standalone.xml work with  with session-timeout in web.xml?

I understand that:

• max-age indicates how long the cookie will live on the browser until it's deleted
• session-timeout  controls how long the servlet container will "keep alive" an inactive session

I do not know how the browser treats 'writing the session cookie'..whether that

The context here:

• users complain about getting kicked out prior to the session timeout; they set up a 8-hour session timeout.
• however we have not seen consistent results.
• Additionally, they uses SAML sso which may cause/contribute-to the problem.
• I know that when i've logged in 'without SAML' (we here lack access to the customer's SSO/SAML system)  I have seen long-lived sessions (i.e. login, visit a page, come back 4 hours later, hit refresh: everything works)

Our Inconsistency: Max-Age vs Session Timeout

We have an inconsistency as follows

A. Session Cookie in standalone.xml

            <servlet-container name="default">

                <jsp-config mapped-file="false"/>

                <session-cookie max-age="3600" />

                <websockets/>

            </servlet-container>

B. Session timeout in web.xml

   <session-config>

      <session-timeout>480/session-timeout>

   </session-config>

F12 Tools say: Undertow does not set the Max-Age Attribute

I checked F12 tools (firefox' firebug and chrome's internal f12 tool).

Both show JSESSIONID has no "max-age" or "expires"

thanks in advance!

[pferraro]

It doesn't make much sense to use a max-age that is less than the effective session-timeout.  A session-timeout of 480 means the session will be deleted after the session is idle for 8 hours.  However, a cookie max-age of 3600 means that the user's browser will only keep the cookie containing the reference to the user's session ID for 1 hour.  This means that if the user is idle for more than an hour, unless the session id is encoded in the request URL (e.g. via HttpServletResponse.encodeURL(...)), subsequent requests will lose their session reference and a new session will be created.  The original one will eventually expire after another 7 hours.  As to whether SAML is responsible for the observed premature logouts, I don't know.