Custom session replication now built into Jetendo CMS
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.
Bookmark & Share
Most Popular Articles
- Mass virtual hosting security tip when using a reverse proxy to connect to other servers
- Solution for MariaDB Field 'xxx' doesn't have a default value
- How to lock Windows immediately upon smart card removal
- Stop using sleep mode with Windows Bitlocker for better security. Learn how to use hibernate in Windows 8.
- Is Google Public DNS actually better then your ISP?
- Pros and Cons of CFML vs PHP and other languages
- My dog survived eating a box of Oreos
- Planning a system to visually create responsive data-driven web page layouts & widgets in the Jetendo CMS browser interface