This has been discused several times befor and the conclusion is that these obstructions are wrong. What if the user loses its credentials and he is still considered loged in. He cannot log in again. If you bind the session to a IP address then you create problems for users behind proxy farms. Your option (b) is virtualy the same as doing nothing about it at all.

Chris W. Parker wrote:
Hi.

Ok I've got the logging in of customer accounts settled but what I need
to work into the system is that of preventing more than one instance of
the same account.

If I logon right now as testuser1 on ComputerA and then go to ComputerB
and login as testuser1 it'll work just fine. What I want to do is one of
the following: (a) prevent the second instance of testuser1 from
succeeding, (b) logoff the first instance of testuser1 when the second
instance authenticates.

I know I'll have to keep a database and store the following: username
(or user id), session id, time of login, and/or time of last action.

Option A is very easy. I can easily look in the database and see if that
person is already logged in. If they are found in the db I just refuse
the second login attempt. Option B on the other hand seems a little more
difficult. As far as I've thought it out so far I'll have to check the
db on each page request to see if the user is still valid. That is to
say, if the second attempt is allowed to login I would have to change
the users session id from the first instance to the second instance.
Then when the first instance goes to a new page the application would
say "Hey wait a minute buddy! Your session id is different than the one
in the database. You've either timed out or someone else has logged in
with the same username."


Am I thinking this through correctly? Comments?




Chris.


-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to