6

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?

SteB
  • 738
  • 1
  • 8
  • 22

2 Answers2

12

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:

  1. 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".
  2. What if users never log out, but simply close their browser?
  3. 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.

Brandon
  • 4,555
  • 19
  • 21
  • Thanks for your thoughts, it's given me a lot to think about. This is basically "enterprise" software (I hate that title), so: 1. The number of users tends to be fairly low (avg 5 - 20), users tend to have a specific reason for logging in (we'd only count sessions with valid userids). 2. I though you could invalidate the session (remove from DB) when it times out. 3. That is something I need to look at, also users opening multiple tabs in a browser. – SteB Mar 17 '13 at 15:59
  • Why does enterprise imply 5-20 concurrent users? I maintain an enterprise web application which typically has 3,000 to 5,000 concurrent users on it. And what is a valid user id? – Brandon Mar 17 '13 at 16:02
  • Typically we're at the smaller end of the market (average per-client users are 5-20, some are 100+). Perhaps line-of-business or SMB software might be a better description. A valid userid is when a user has authenticated and logged in. – SteB Mar 17 '13 at 16:05
  • 2
    You might be able to tell PHP to invoke some callback when the session times out. I haven't used PHP in many years, so I'm not positive. But given that PHP code only lives in the context of an active request, I assumed it wouldn't be possible. – Brandon Mar 17 '13 at 16:11
  • Of course you can do this in PHP (you can do it in any language). The process lifecycle is irrelevant. This can be done simply by updating the database login record with the last session activity timestamp whenever an HTTP request comes in. Your "active sessions" are those records in the table with a last activity timestamp less than whatever your idle timeout is. You can have a cron run something periodically to clear these timed out sessions. – FtDRbwLXw6 Jun 24 '14 at 20:01
1

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.

Sam
  • 6,152
  • 2
  • 20
  • 34