For years we’ve been doing some basic checking in the WebSession.Open event of our Xojo web apps. First, we check to see how many open sessions we have and if it’s over a preset number. The second check we do is to see how many open sessions we have for the current IP address. We set it to something low like 10 because when some joker decided a few years ago to prove that Xojo web apps suck. He opened up our training app, and then hit refresh 150 times and then complained about how unresponsive the app was (thus proving his point that Xojo web apps suck, I guess).
In our apps, if either of those conditions is met we use a ShowURL to redirect to one of the webpages on our regular website to show the user that the app is either too busy or something bad happened. It’s worked decent enough that I’ve never revisited it until this past weekend when several users alerted me to the redirect never clearing. Since I couldn’t login to my own app I restarted the server and everything was fine again.
I tend to use a log file on my web apps to track certain conditions and this morning I added more information so I could track this more. I just happened to be monitoring the app (in my browser) when my session count spiked to around 50 in just a few seconds. Looking at the new information in the log file the IP addresses were all over the place. An attack? I dunno but it sure seemed like it.
Unfortunately, the session count didn’t go down immediately like I expected it too and, in fact, it didn’t go down even up to an hour later. I had over a hundred open sessions before it stopped (did Xojo Cloud security close the port?).
When that happened I started looking at code. Some of this code I hadn’t looked at in a year or more. Basically the code did the two checks in the WebSession.Open even and if the function returned true I immediately tried to call WebSession.Quit.
Guess what happens when you do that? If you guessed nothing you’d be wrong. It generates a Nil Object Exception first with the following stack trace:
Function WebSession._WaitingForSync() as boolean Sub
And after that then it does nothing. The WebSession never quits – ever – until something kills the app.
My solution was to put a timer property into the Session and if I meets my quit conditions start the timer and in the action event (using AddHandler) quit the Session. Seems to work as expected now.
This is filed in Feedback <feedback://showreport?report_id=35794> and it appears that it’s been verified. There are some additional details on their response. They know why it’s happening at least. Let’s hope this one gets fixed sooner rather than later.
I’ve seen various people have issues with WebSession.Quit over the years. This might be the root cause of some of those.