Limiting simultaneous logins

[sjariri]

What I am trying to do is to limit the number of simultaneous logins of each registered user. Currently each user will be authenticated against a database and a PHP session will be created for him (say $_SESSION['username']). Then we will check for this session in all pages.

Which solution do you recommend to limit the number of simultaneous logins by each user?

Thanks in Advance,

[henry0]

Since you are using session instead of storing sessions in the default temp file I will (anyway it's a better solution) store the sessions in my DB

then add to the login script: if!session etc....
allow for login and else if session exists
"you cannot log twice..."

[sjariri]

I believe, using PHP session procedures, we are already storing a text file for each session of the users in a directory on the server as well (having names like sess_6959087a691fe9f21b7c02d060e9e60f, etc.)

So what are best practices? Storing number of sessions of each user in database (say, table ONLINES), or searching the session text files on the server (if it helps at all), or any other similar practice...

[henry0]

I would save the sessions in your DB
Allowing a wider range of options by using the stored session ID

[victor]

This is what I do:

when someone logs on, I generate a cookie that looks like
"user-name+35533266367"
where 35533266367 is a completely random number each time. That's saved in the user record, overwriting any previous logon cookie

That has several advantages both the user and me:

Second logons automatically cancel the previous logon, so only one connection per user name at once

If they walk out of an internet cafe without logging off, their exposure time (the period someone could retrieve and use the cookie) is limited until their next logon or the cookie expiry time

If the do log off, I initialize their user record entry. So someone scouring their hard drive for cookies won't find a usable one. [Finding a user name and password is another matter of course]

No need for a database or extra table. Just a field that'd probably be in the user record anyway.

That's with cookies. Sesssion-ids can work the same way.

[Stormfx]

The problem with the cookie-only method is in the case where a users uses a second computer to make the login attempt. That's why it's recommended to store the information on the server.

You can have an extra field that stores the session's active state. That way, if the session IS active, you can tell them they need to log out before they can log back in.

Just be careful when you implement it, so that you don't prevent them from opening an additional instance of their current browser (unless that's what you're intention is).

[john_k]

I use a method similar to Victor's. I have a login table that stores a loginid, sessionkey (random long string), profileid, isvalid flag, login date/time, last activity time, etc. When someone logs in, the login procedure verifies userid & password, then invalidates any existing rows in the login table for that profileid, then adds a new row to the login table.

The effect is that the last instance to login wins.

[victor]

The problem with the cookie-only method is in the case where a users uses a second computer to make the login attempt.

The method I described does not have that problem. As John_k says, by having a unique cookie [or user session id] for each logon, the "last instance to login wins."

I avoid having a separate logon table as the cookie [or etc] contains the userid. That may be considered a security exposure on some systems, but (as the HTML will usually contain the userid somewhere), it's not one that bothers me for the applications I support.

That's why it's recommended to store the information on the server.

Maybe I wasn't clear. The logon validation information is held on the server. The process is:

get the cookie

use the 1st part (userid) to read the user record

if the 2nd part (unique number) matches, they are logged on; otherwise, not.

[Stormfx]

Ahh...

No need for a database or extra table. Just a field that'd probably be in the user record anyway.

is kind of misleading :)