Losing sessions

[Steve Workings]

Within the last few weeks, many users have reported a loss of their session. I don't know why.

We used to have this sporadically, so to help manage this, some time ago I added a callback every 15 seconds to be sure a key session variable existed. If not, users get a little sad cloud message and then are taken back to login.

    vUser = a5ws_getcurrentuser()
    if vUser = ""
              .......
    end if

Server session timeout is set to 15 minutes. The callback, of course, keeps this alive for as long as the user wants, which is what I want.

I can detect no pattern. I've watched it happen to me while just sitting on the page doing nothing at all, and I can't find anything in the Chrome console or server logs to help.

Some users get it once in a while, some users get it every few minutes. It can happen all day to one person, then not at all for a long time again. And it happens to users around the world - no single location or region.

We're using Alpha Anywhere Classic, on two servers hosted by Google cloud with Cloud Flare in between. It happens from both servers.

And we're on an older build 5667_5254, obviously have not upgraded for a while so it's not due to a bug in a patch.

Any ideas?

[Lenny Forziati]

Re: Losing sessions

Steve, are you sure session affinity is working correctly? What your describing is exactly the behavior caused by a user that was using server 1 getting directed to server 2 instead since sessions are local to the specific server.

[Steve Workings]

Re: Losing sessions

Thanks Lenny. I wonder how I can check that? We've not changed anything.

We have the Google load balancer with session affinity that points to the two servers. Each server has 4 instances running with a software load balancer managing session affinity.

[Steve Wood]

Re: Losing sessions

There are lots of discussions online about Google Cloud losing session affinity for various reasons. See the second post on this thread: https://stackoverflow.com/questions/...ssion-affinity.

You are using my Load Balancer on the two machines so I can say that the number one reason that a user is moved from one Instance to another is if the target Instance is slow enough to make it fail health check. If it fails health check then the load balancer takes that instance out of service until it passes a health check. Active users on that instance will get failure and if they refresh their browser will go to a different Instance. I think when they change instances they will get a new session ID. One thing I don't know is if Google Cloud detects that the instance fails the health check does that mean it will try another instance on the same machine or automatically try a different machine (i.e., does Google even know about the local load balancer on each machine)?

I should test to see exactly what happens to session variables when the user is moved to a different instance.

EDIT: I notice our avatars to the left here practically match.

[Steve Workings]

Re: Losing sessions

Thanks Steve - a good link.

I browsed more broadly through some of our logs just now, and have reason to suggest we're getting a bit overloaded with automated hacking attempts. I'm finding big groups of .php requests -- several per second per instance in many places. I thought we blocked those through Cloud Flare but have asked for a review of that by our Cloud Flare guy (Mark).

[Steve Wood]

Re: Losing sessions

I know this is a bit of a hack to thwart PHP and other attacks I use a 3rd party Block-by-IP tool where the blacklisted IP addresses are just a text file. I feed that text file from an xbasic script that runs on the index.a5w page and if the request has ".PHP" or other unwanted values in the URL, I post their IP address to this file and they are forever blocked in about one minute.

[Lenny Forziati]

Re: Losing sessions

Steve Workings:
You would benefit greatly by moving your application to the Application Server for IIS.

1. It will address your immediate problem by eliminating the need for session affinity. You can use an IIS session state provider that shares sessions across all instances so a user's session will always be accessible regardless of which server handles their request. You would no longer be dependent on session affinity working properly at either the Google level or the local machine level.
2. It will address the additional load caused by the malicious PHP requests you are seeing. IIS will handle these requests directly and serve up a 404 (or other error page as appropriate) and the Application Server will not even need to participate so will not be directly impacted.
3. The need for multiple Application Server instances is removed. This also means you can eliminate the software load balancer on your Google instances. This simplified configuration makes setup and ongoing maintenance easier.
4. IIS Application Pools automate load distribution and overlap EXE restarts to manage memory without any interruption in service or loss of session state.

Steve Wood:
If a user is directed to a new instance of the Classic Application Server, their session will not be valid on that instance. Upon that first request, the new instance will create a new session, and that session will have its own unique session ID.

I know this is a bit of a hack to thwart PHP and other attacks I use a 3rd party Block-by-IP tool where the blacklisted IP addresses are just a text file. I feed that text file from an xbasic script that runs on the index.a5w page and if the request has ".PHP" or other unwanted values in the URL, I post their IP address to this file and they are forever blocked in about one minute.

This is a very good technique to help protect your server. This is similar to the type of functionality that CloudFlare and other services provide, and it is worthwhile even if you subscribe to one of those services and/or use IIS. It it relatively easy to set up, and the more layers of security and protection that you have, the better off your systems are.

[Steve Workings]

Re: Losing sessions

Thanks as always for your generous input Lenny. We're probably going to be with the classic server for a while.