Lucee \ Tomcat session persistence between browser restarts

dev support
1

Hi,

Lucee 4.5.5.006 final
Apache Tomcat/8.0.45
Java 1.8.0_144 (Oracle Corporation) 64bit

I’m not sure if this is the place or not, but I’m having trouble getting a session to persist between browser restarts.

I am sure this used to work, but somewhere in the sands of time it stopped.

So, the JSESSIONID cookie being served from my sites on a single server, has an expires of “Session” - so when the browser is closed (pretty much any browser), the cookie is deleted.

I think it used to have a max age, that means it would only be deleted when the max age was met or the site told it to end it.

The reason for this is so that for example a user puts something in a simple basket, the server has session management set to 12 hours, a user closes the browser, can re-open to the same site, and if still within that same 12 hours, and the session is still available on the server, the user can continue. If the session is not available on the server or the cookie has expired, a new session is generated.

So the question, how can I change the max-age of a jsessionid cookie?(preferably via cfml \ lucee on a per context basis)

Thanks

2

Hi Tim

As long as I’ve been using them, (a good few years now, first in ACF then Railo/Lucee) JSESSIONIDs have always been session only (i.e. they die when the browser is closed).

Generally this is the behaviour I want, and I assumed it was the only option. But it seems that in Tomcat at least you can make them, and therefore the user’s session, persist across browser restarts.

You just need to open up your <lucee-install-root>tomcat/conf/web.xml and change the following:

<session-config>
  <session-timeout>30</session-timeout>
</session-config>

to

<session-config>
  <session-timeout>30</session-timeout>
  <cookie-config>
   <max-age>1800</max-age>
  </cookie-config>
</session-config>

followed by a restart. New sessions should then survive browser restarts for the number of minutes you’ve set.

3

This doesn’t quite answer your ‘jsessionid’ point, but I’d think carefully before extending session times to accommodate extended basket persistence.

Security-wise, you want to keep your session time as short as possible (see the OWASP guidelines: Session Timeout | OWASP Foundation) since at some point, you’ll probably be dealing with logins / payments / addresses etc

I’d see if you can introduce basket persistence independently of the session (perhaps a separate cookie, or a cookie identifier to a database basket storage)

I’d also question whether a customer would expect session persistence if the browser is closed (half way through the checkout and close browser - would you really expect to pick up where you left off?)

1 Like
4

Thanks for the feedback.

@Julian_Halliwell, thanks I am going to give that a try.

@Geoff_Parkhurst, I understand your advice, I used the term basket so as not to detract from the question, but the actual application is not a customer facing basket, it’s an organisations internal dashboard that produces some fairly complex transient data over time that we don’t want to reset and build again if possible, and is not suitable for storage

Part of the application is using LCD wall screens that cycle between pages in the application, so autonomous users rather than real users. This is not being done in a standard web browser, and because the cookies are session cookies, the session they are using is being cleared as they cycle between several internal web pages on different servers.

We have a fairly complex but effective method at the application level to set server level sessiontimeout depending on the users use of the application that ranges from a 2 minute session through to a 5 day session.