Custom session replication now built into Jetendo CMS

  Follow me: Follow Bruce Kirkpatrick by email subscription Bruce Kirkpatrick on Twitter Bruce Kirkpatrick on Facebook
Sun, Jun 15, 2014 at 7:40PM

There are a bunch of ways to replicate session data especially with Railo since it supports clustering multiple servers without licensing limitations, but I wanted fastest, most reliable and most secure approach, which requires a custom effort.

I replaced the way sessions are retrieved and stored to use my own code for all the sites and went live today.  It's working great.  It was surprisingly easy to find/replace all the references to session scope in my app.

I'm using the same session ID generation that Railo uses, which is createuuid().  I also save the user agent, IP address and access date with each session to ensure they match / haven't expired before allowing a user to access the session data.

Additionally, I learned that it is possible to associate the Nginx SSL session ID with the Railo application's session ID to make it impossible to steal the users' cookies as a way of logging in.   So I added this feature for my SSL sites.  This works because the server and browser keep the SSL session id in memory as long as you tell it to, so I made the timeout longer (30 minutes instead of 5 minutes) to match the session timeout for Railo.   Now a user will be logged out whenever they close their browser or when the server reboots, but this is a great security feature for sites where you want that extra level of security.     If the user uses the permanent login feature, they will still be able to auto-login, but the system will need to re-authenticate each time they reopen their browser, because of the new SSL session id and any extra session data that was stored will be lost. It seems browsers renegotiate SSL sessions way too often for this to be useful.

I wrote very efficient code for transferring the session data between 2 or more servers using HTTP request to keep them in sync every few seconds.  Each server keeps track of the last time it synced with the other servers, and when requesting new date, it sends that the last update date, so that the least amount of data possible is transmitted over the network.   So if a user is logged in on server 1, and that one shuts down, it will be possible to keep their login alive when they visit server 2.   Only a few seconds of session info would ever be lost.   However, if the user was on an SSL web site, it is not possible to replicate their session data because the ssl session ID resides in Nginx and it is not transferable.

Because of writing my own session replication, I can guarantee that session replication has caught up with the other servers before bringing a server back online after a reboot/maintenance etc.    This makes it easy to cycle servers in and out of maintenance without affecting the active users logged into the system.

I've been working hard trying to enable easy clustering of 2 or more Jetendo CMS servers as part of the open source project.  This is something I'm working on in the Jetendo Server project on github.


Bookmark & Share



Popular tags on this blog

Performance |