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.