Re-establish a session after server reboot

[ACS LLC]

(CF2016/Win 2022/IIS 10)

I want my users to be able to stay logged in for a long period of time, however as Microsoft release it's updates every second Tuesday of the month, I like to make sure these are in place asap and this almost always requires a reboot.

A reboot loses all of the sessions, so the users would have to log back in again. I believe (well according to my new friend ChatGPT) early versions of CF used to have an option write the session to a file so it could be recovered but now it's memory or Redis.

I did find a thread in the forum regards editing of Tomcats config, but I was a little uncomfortable doing that.

Does anybody have any solutions to this?

My thought is that I'll write a big unique token (or two) into a cookie and stored in their database record, and when they return if they are logged out, use that to reauthenticate them and create a new logged in session, a "remember me" so it automatically logs them back in seemlessly.

One downfall of this is that if they were in the middle of something, it's going to lose whatever that was and kick them to the start page of their dashboard.

Second to this, I was just thinking, if the sessions are going into memory, does that mean that if I leave the length of the session too long that it's going to just eat up lots of memory over time as my user base grows?

Appreciate any thoughts.

[Charlie Arehart]

The feature to store sessions in Redis would seem just the ticket for you. It was added in cf2016, and is available for all editions (standard and enterprise). It requires no change of code nor any tomcat config. 

If you may have dismissed it for your "not having redis available to you", that can be easily solved and for free, on Windows or Linux or Mac, or via remote services. If there may be an issue with it "requiring you disable cf's j2ee sessions", that can be addressed also. Before I might elaborate on those, I'll await your clarifications.

Finally yes, the longer your sessions last and the more of them you have, the more cf heap memory you'll use--influenced also by what you put into each session, of course. Beyond that, there are also security risks in longer sessions (increasing the timeframe during which a bad guy could try to impersonate a given session--though thankfully more and more security features try to prevent that).

Let us know what questions might remain. 

[ACS LLC]

Thanks for the reply Charlie. I've never used Redis and have zero knowledge of how it works. j2ee is already disabled so I'm good in that department

I did find a link from a couple of years ago that you replied to

https://coldfusion.adobe.com/2022/03/trying-redis-coldfusion-caching/

I see the person that wrote the article used it remotely on AWS.

Ideally I'd install it locally on my own server. Reading it is says memory storage for sessions, so is it just another place to store them in memory and if that server was to be rebooted I'd be back to square one, or can it write to disk so  that when I reboot the server it can pick up again?

Are you aware of any documentation on how to install and config this on a CF server?

Thanks

[Charlie Arehart]

To your question of whether a reboot would have you back to square one, that answer is no, otherwise why would I have proposed it? 🙂 Redis is like a db server. And just like a reboot doesn't affect that, it wouldn't affect redis. 

As for that article, it only touches the surface of the topic, and as for installing redis locally, no, nothing in the cf docs discusses that, either--just as the docs never discuss installing any database. 

But I understand how confusing it all can be, and that article is too surface to get most people going IMHO. It also makes an unneeded reference to enabling redis for cf caching, which is NOT needed when using redis just for session storage, as I note in my comment there.

Anyway, as I said, installing redis locally CAN be done, and I'd said I'd offer more once I heard back. 

Briefly, it's available free for all OS's, but a binary installer for windows is harder to come by. As a workaround, I'd recommend installing cf's API Manager, and in the installer choose only to implement its "data store" component, which is redis. I could say a lot more, but let's see if that may suffice for you. (One can also implement Redis quite easily via Docker, but that may not be a suitable option for you.)

And as I'd said there are services, free and commercial, that offer redis remotely...not only in aws and Azure but dedicated services like redis cloud.

Again, in cf all one needs to do is configure the cf admin memory variables page to point to that wherever it is. Try it from a developer machine. Restart cf, login to your app, then restart cf, and your app should remain logged in. 

Let us know how it goes. 

[ACS LLC]

Thanks Charlie, I shall roll up my sleeves and jump in feet first 🙂 I did look at a few Youtube videos but they were deep into the database side of things. Once I wrap up a couple of things I'll give it a go in a few days, what could possibly go wrong 😉

[BKBK]

The problem to be solved is how to reactivate logged-in users after a server restart. The way I see it, that is not a session problem, but a login problem. After all, you can be associated with a session without being logged in.

You could solve it in a simple way, as follows. In onApplicationStart, define an application variable, say, application.currentLoggedInUsers, that keeps track of all users who are currently logged in. The variable application.currentLoggedInUsers may be a struct, for example.

The moment a user logs in, his or her details are added to the struct. When a user logs out, his or her details are removed from the struct. 

Now write code to save these details to the database. That is the code that you will run before rebooting the server. Also write code to read the login details from the database, and log every user in.  That is the code that you will run after rebooting the server. 

[Charlie Arehart]

Sure, but if indeed one's logins ARE tied to a session (as seems the case in nearly all cf apps I've ever seen), the use of redis does all this sabing/restoring for you--and on a more granular level, not all at once at shutdown or restart, and alleviating any need to trigger such a process. The latter seems rather perilous, especially if cf does or becomes unresponsive.

Not arguing against your proposed approach. Just adding more context, in contrast to what I'd proposed (being a mostly built in feature). 

[ACS LLC]

I've actually got another solution. as per the other thread I currently had open with the performance issues, I decided to try an install of Lucee. I didn't know that Lucee has the ability to write a session to file, so that would easily solve the problem. As it's also solved my speed issue and gets me away from the license costs of an upgrade of an old unsupported CF2016, I decided to go with Lucee.

The only thing I now have to give some thought to is whether I want to give the user the ability to stay logged in, so, if they don't return for a while and the session actually expires, use a token or two in the cookies to log them back in and create a new session.

[BKBK]

There are ColdFusion applications that don't use sessions. For example, Studiemeter and StudieReader.

Studiemeter has hundreds of thousands of users and ran on ColdFusion for more than 20 years. For most of that time, it didn't use sessions.

[Charlie Arehart]

I didn't say there weren't any. But can we leave it at that? Your stance is clear, and I hope mine is now. 

[BKBK]

The latter seems rather perilous, especially if cf does or becomes unresponsive.

By @Charlie Arehart

It all depends on how you implement the solution.

[Charlie Arehart]

Sorry, but I'd argue that writing out all sessions at shutdown will always be perilous, regardless of implementation, for the reasons I stated. It can also be crippling to fast restarting of cf, with lots of sessions.

But Mark (acs) has moved on. Perhaps we should as well.  If you want to elaborate, perhaps a blog post with all the details would be valuable, and then you could reach more people with your suggested improvement. I'm planning the same on cf redis sessions storage. 

[BKBK]

Sorry, but I'd argue that writing out all sessions at shutdown will always be perilous, regardless of implementation, for the reasons I stated. It can also be crippling to fast restarting of cf, with lots of sessions.

By @Charlie Arehart

You may be right. 

Nevertheless, let me clarify, before we move on, that my suggestion is about storing login information, not session information.

One advantage of this approach is, for example, that the saved login could be given a time-to-live. Then a user's login is reactivated only if the user re-visits the application within the time-to-live.

[BKBK]

I want my users to be able to stay logged in for a long period of time, however as Microsoft release it's updates every second Tuesday of the month, I like to make sure these are in place asap and this almost always requires a reboot.

A reboot loses all of the sessions, so the users would have to log back in again. 

...

...

Does anybody have any solutions to this?

...

...

One downfall of this is that if they were in the middle of something, it's going to lose whatever that was and kick them to the start page of their dashboard.

Second to this, I was just thinking, if the sessions are going into memory, does that mean that if I leave the length of the session too long that it's going to just eat up lots of memory over time as my user base grows?

By @ACS LLC

Again, given your description, whether you're using Lucee or Adobe ColdFusion, the relevant subject is "Re-establish login after server reboot", not "Re-establish a session after server reboot".

In any case, you should probably not worry about sessions consuming much memory. Unless the amount of RAM available to your ColdFusion application is small or there are hundreds of thousands of concurrent users.

[ACS LLC]

My solution looks like it's going to be Lucee set to write sessions to file, and POSSIBLY adding a cookie with tokens, so if the user goes away for a long time, then I can use the cookie(s) to log them back in and create a new session. If I user goes away for a reasonable amount of time, then I don't think it's the end of the earth for their session to restart, especially if I can do it automatically (at least in my case). If they choose log out, I kill the session and also remove the cookies.