I’ve been asked to look at converting our traditional client-server software into a web-based version (using PHP).
One of the first questions from management was how we’d limit the number of concurrent users, currently handled by our licence manager that every client connects to when running our apps.
My initials thoughts:
- Check the number of open sessions on the server (only with valid users that have logged in).
- Logging each login/logout to a DB table and counting them.
Is there a standard/best practice way of limiting the number of concurrent users who can log into a web app?
Be very very very careful with this. Make sure you have an idle session timeout and that you know what it is. Document it. Configurable would be great too.
The reason why this is dangerous on the web is that the lifecycle of a session is not as simple as it appears. People tend to evaluate sessions based on the happy path. User logs in, then logs out.
But some things to consider:
- When does a session begin? Sessions do not begin at login. They begin at first HTTP request. Even if login is the first page visited, what if 100 users visit the site but then instead of logging in, leave? You have 100 sessions that are essentially “lost”.
- What if users never log out, but simply close their browser?
- Can a user login to the same user account from two different HTTP sessions? If not, what if the existing session isn’t active any more. If a user logged in, closed their browser, started up the browser again, they would be unable to login until their previous session “times out” on the web server.
I have seen some of these concerns handled. It can be done. But it’s complicated, so be warned.
If you choose the counting logins and logouts in the database approach, you still have some of the same problems. What if a user never logs out, but the session times out? I have seen this solved in Java EE by defining a SessionBindingListener, so that when a session times out, we can go to the database and invalidate their login. I’m not sure if PHP can do the same thing. As PHP code is only invoked when an HTTP request comes in, I doubt it can be done. But I am not a PHP expert.
5
The way that I would implement this is not at session start, but when a user first logs in to the application.
The approach that I would take would be a sliding token that gets updated with each authenticated users HTTP request.
You could either write a CRON job or invoke a script at each request to quickly delete expired tokens from the database.
This would allow you to operate logins separately from sessions, as a session starts for each unique user who connects. It would also allow you to operate a token based on a user and allow each user multiple logins. Of course, this may not be a requirement, but at least the same user logging in on the one machine in two web browsers could count for one license.
Bare in mind too that if you are going to be deploying this within enterprises you may want to look at obfuscation of your code to prevent tampering / viewing.