One user only!

[bcoffin]

Hi All.. have a backend where users may login and make changes and such.
I'm wondering if there's a good way to only allow one login with that account.

read: somehow perform a check to see if someone is currently logged in?

I'm concerned that if my users don't "logout" then it will be stuck forever logged in, otherwise I could just record an "in" on login and "out" on logout. Isn't there a better way to do this? Furthermore, is there a way to see how many [unique] users are logged in at any one time?

I've seen it on phpbb that shows who's currently online...

[the_oliver]

I do this by recording there session number in a database.  Every time they log in the session number is updated agains there username.  The for a secure area i check there users session number against the one in the database, and if they dont match, the user has to log back in agian.  As the session number will always be unique, it insures the user can only be logged in once.  The other way to do it is through cookies. 

As the the seeing who is logged in, you can also do this through having a database marked with the login time.  Have a task remove the time when they log-out, or after a serten period of inactivity.  Perhaps these ideas could be of use to you?

[roopurt18]

Add a DATETIME field, I'll call it curr_activity, to your users table and initialise it to NULL.  When someone logs in set the field to the time that they logged in.  Every time they view a page update the time in that field.  To allow only one login per account you simply do not let them log in if that value is non-NULL.  In order to prevent someone from being permanently logged out, have a cron scheduled to run every [i]x[/i] minutes and set all curr_activity columns older than [i]y[/i] minutes to NULL.

(EDIT)  I could be wrong, but I don't believe adding the session ID to the DB is any more secure than a simple DATETIME field.  The session ID for the client is seen in the URL or in a cookie which can easily be given to another user, assuming two people are working together to accomplish something.  I don't know if there's any way to truly enforce a single login per user; the most you can do is make it annoying enough that most people would give up trying.  And that would probably come at a time investment that is more than it's worth.

[bcoffin]

there's no way to auto "logoff" when a session is killed?

[bcoffin]

the_oliver, i like this plan.

a. when logging in, check if there is a session open corresponding to the last session id recorded for that user.
b. if there isn't a session open, log the new session id and allow login
c. if there IS a session open that corresponds to that user's previous session id, then show error

how do you search the server for sessions by id?

thx
benny

[the_oliver]

You have to store the uses ID some how, and use this to pole the database for the users last know session number.  And yes if it does not match with the users current session number then you have a page saying that they were logged out for security resions and to log back in.

*roopurt18
How does using date/time stamp stop more then one user being logged in?  Why could two people not log in at the same time, with the same user name, and both be updting the time stamp.

and [quote]is seen in the URL or in a cookie which can easily be given to another user[/quote] sorry but this is rubbish!  The session is not displayed in either of these.  Althogh it is possible for the session to be found it is not possible to replicate it.  Sessions would be infinatly more secure then a date/time stamp.


When they try to log in there is no need to check for a previus session.  Just write in the number of the current one.  Anyone using the old session will be logged out.  Also if you use the date/time method there is a delay while wating for cron.  This way there is no time delay till they can log in again.  The only way there session number will change if they exit the browser.  This also meens if they exit the browser, no one can use the computer strait after them and find the user still logged in!

[roopurt18]

Using a DATETIME stamp allows only one login if you init the field to NULL and disallow anyone from logging in when that field is non-NULL.  The field will be non-NULL when the user first logs in and from their normal browsing.  Anyone else attempting to log in will encounter a non-NULL DATETIME field and your script can prevent them from logging in again.  You need to add a cron job to reset stagnant DATETIME fields to NULL so that a user who forgets to click a Logout link can log back in later.

You're right, the session itself is not stored in a cookie or through the URL, I should have been more specific.  The session ID, however, is.  There is nothing you can do to prevent a legitimate user from logging in and then, knowingly or unknowingly, transmitting their current session ID to another illigitimate user.

http://www.php.net/session_start
"[i][b]session_start()[/b] creates a session or resumes the current one based on the current session id that's being passed via a request, such as GET, POST, or a cookie.[/i]

I'm not saying using the session ID won't work.  What I [i]am[/i] saying is that it [i]doesn't[/i] garauntee only one login per user any more than a DATETIME column and that using a DATETIME column [i]is[/i] easier.

[roopurt18]

If you wanted to eliminate writing a cron job you could do something like this:

Let's say a user logs in today at 3PM.  They browse the site until 3:15PM and close their browser [i]without[/i] clicking your logout link.

Tomorrow the user attempts to log in and receives a message from the site:
[i]Your account is currently logged in.  Logged in at <Yesterday @ 3PM>, last activity recorded at <Yesterday @ 3:15PM>
If this is a mistake you can force your account off by answering your secret question below.  To prevent this from happening again, remember to use our Logout feature.[/i]

Based off this information, if the user currently attempting to log in is legit, they can deduce if they just forgot to logout of the site or if an unauthorized user is on their account.  Further, it allows the legit user to force off an illegit user.

Note that this only controls the login process.  There is [i]still[/i] nothing you can do, AFAIK, to prevent a legitimate user from, knowingly or unknowingly, transmitting their session ID to a malicious user [i]after[/i] they've logged in.