|
|
Posted by Gleep on 08/29/81 11:39
Gordon Thanks for your tip about tracking the sessions in a db. I did consider that but I wanted to
avoid tracking them with table queries.
Here is what I came up with.....
First I wanted to say thanks to everyone writing in help me with this. I came up with this solution
and it works well I think.
The trick to this situation is collecting current session data and comparing against a client who is
trying to login. Note the goal: I want to prevent clients from sharing thier usernames and
passwords with others since this is a subscription based system.
On the login form, I do the standard thing (query) to see is the username exists and if the password
is correct, blah blah we've all done that a million times. But BEFORE I register a session
"validUser" with thier username - I first loop through existing sessions and see if there is a
match. This is how
$OKtoLogin = true;
$handle = opendir(session_save_path());
while (($file = readdir($handle)) != false) {
if( $file != "." && $file != ".." ) {
$filename= session_save_path()."/".$file;
$fp = @fopen($filename, "r");
$contents = fread($fp, filesize($filename));
if(strstr($contents, $userName)){
// if true then there is multiple login attempt, at this point I
// can send them to a login fail page or email them with note
$OKtoLogin = false;
}
fclose($fp);
}
}
if($OKtoLogin){
// at this point it passes validation
// here i would register thier session and pass them into application
}
Note: occationally some sessions stick around for whatever reason and I would have a cron set up at
3:00am that wipes out all sessions with unset() and session_destroy()
It seems simple now, but this took me hours and hour to figure out. It just reads in all the
existing session files, reads the contents of the session, compares it against the posted value
username (which will always be unique new user will not be able have the same username) if there is
a match then I know it's a multiple login attempt and it fails. If there are no matches everything
is cool and they login normally.
I don't have to track timestamps and SID in tables and run quiers to see if flags have been set and
all that jazz. I hope that this code snip will help someone else solve this issue with preventing
multiple logins.
On Thu, 09 Feb 2006 18:52:08 -0000, gordonb.k3i75@burditt.org (Gordon Burditt) wrote:
>>Some suggest create table fields with the session ID and a time stamp.
>>However my clients can spend
>>alot of time on a page and I don't want to force them to re-login, would
>>be annoying.
>>
>>On the other hand, some clients do not logout properly and sessions open
>>active and/or a script that
>>runs the timestamp does not clear that field. Then the next they login
>>the stamp reads that they are
>>active and will not allow them to login.
>
>My suggestion is to keep a database of active sessions. (user name,
>session id, timestamp). Well, actually, I'm not sure you really
>need the timestamp. If a user logs in, delete all the previous
>session records with his user ID and create a new record with his
>session ID. When a user tries to access a page, check for the
>session record by session ID. If it's not there, redirect him to
>the login page. In other words, if the user tries to log in twice,
>blow away the *OLD* session(s), so if someone tries to continue
>using them, they have to log in again. If the user explicity logs
>out, blow away all the session records with his user id.
>
>If the user did not log out properly, this will do no damage, since
>he won't use that session ID again. If there are two (or more)
>users sharing a login and trying to use it simultaneously, they
>will keep bumping each other off. You don't prohibit multiple users
>but you make account sharing a real nuisance. It gets even worse
>with a dozen users trying to share an account.
>
>>I'm an experienced PHP programmer yet this task has got me going
>in >circles. Everytime I think I >have a method worked out - there
>is a reason why it won't.
>
>You can also use the approach of detecting multiple logins (timestamp
>needed here for telling the difference between an abandoned session
>and multiple users) and if there are too many too quickly, send a
>nasty email. Realize that this might false-trip occasionally so
>you only send email if it happens several times in a few days. Oh,
>yes, tracking IP addresses might be useful as evidence in case the
>user denies sharing his account. Perhaps his password was stolen
>(by a family member he shares the computer with?)
>
> Gordon L. Burditt
Navigation:
[Reply to this message]
|