Limit number of users accessing a web ASP .NET application

Question

Hi everyone

I am wondering how guys out there work on limiting number of users to a web application. Sometimes you may say you want to limit the web app to only handle say 20 users at a time. Our company sells their applications based on a number of licenses, but we are not sure what the behaviour could be in a web app.

I've seen the some suggestions out there saying you can flag a user account as "LoggedIn = True" when a user has logged in. The each new successful login attempt checks the number of "LoggedIn = True" records. If it exceeds the limit, then the user is rejected.

How will unexpected input be handled in this case? What if:

• The user doesn't click logout, and closes the browser
• The browser crashes, and the user doesn't get a change to do logout
• Network connection breaks, electricity on the client goes off etc etc.

All the above will still have the "LoggedIn = True" flag set and contribute to the number of logged in users. This may unintentionally block out genuine authenticated users.

I am looking more for ASP.NET solutions if possible

Any thoughts on this?

Many thanks

Answer 1

Assuming your user authentication is somehow session based, then the answer to all your "unexpected" cases (which will actually be the norm - people rarely seem to log out of web applications) will be that those user slots become free when the session times out. So you'd need to investigate usage patterns of your application. If you get a lot of people logging on for a couple of minutes, but no more than that, then a 30 minute session time out would mean very few people actually get to use the application.

The fundamental problem is that web applications are inherently disconnected, so you can't monitor what a user is actually doing between requests for a page. Normally, you'd sell licences for such an application for specific users (so if a company buys 20 licences, that would give them 20 user names and passwords). Then you could certainly prevent multiple logons by the same user name and password, by either refusing the second logon or deactivating the previous one (which is probably the better approach in case someone has genuinely moved from one machine to another without logging off for one of the reasons you outline).

Answer 2

The most common solution is to have an activity timer. You can assume that an active user will make at least one request within "X" amount of time -- say 5 minutes or so.

You can enforce this by putting an ajax-style async request triggered off a timer that starts when the page loads. For example, if your'e assuming that all active users will make at least 1 request every 5 minutes, then each page will request an empty (but no-cache) page every 4 minutes. That way, as long as they have the browser window open, you'll always have activity from that user. Again, this is handled by asynchronous requests, not by any sort of reload directive. This makes it absolutely transparent to the user.

As an added bonus, see if you can make that ajax request pull down some useful information, rather than just enforcing licensing limitations.

Answer 3

As David points out the main problem is to differentiate between idle users and users that have left your application.

A possible solution would be to keep a low session timeout (say 1 or 2 minutes) and using a callback function to keep the session alive for idle users. Then you could increment a counter in Session_Start and decrement it in Session_End and use it to keep track of the number of active sessions. If the number of active sessions goes beyond your limit you would redirect the new user to a page that abandons the session and tells the user that you have too many visitors at the moment.