I used to keep a "last_action" timestamp in the user's table of a database. Every time a user made an action, it logged the time. I also had another table that logged what actions they took and at what time, but that's beside the point. I used the last_action field to determin if the user was online or not on the client.
Also, when one user made an action, the server searched the database for users who were inactive for, say, 5-20 minutes or so, and that's how I determined if users were not online- even if their PC crashed or they couldn't log out for whatever reason.. Maybe they just walked away from the PC. So the program looked like this:
(psuedo-sql):
Code:
Tom takes some action.
- update users where username = Tom
- - set last_action_time = now, online = true
- update users where last_action_time < (now - 5 minutes)
- - set online = false
Now, to assure that the same user ID is not logged on two different times is different. If you don't have a persistent connection that's hard to do server-side, say, if they're using the same PC or the same network. That is something the client should do. You can have the server create a random
session string, and send that to the client, then expect the client to reply with the same string every request. But that can be bypassed by a script-kiddy. A persistent connection via sockets is simple.. If there's more than one socket active for the same user, then there's more than one client using the same user.
A TCP connection such as HTTP is much more difficult to keep track of. You can have the client create a random ID every time it is opened, and use that, but again, a middle-man program can hijack the request/responses and make it look like one client is open when 2 are.
As far as protecting people from being logged in on 2 or more different networks, you can just check the IP address.. But I'm sensing that's not the real problem. Without a persistent connection, it's tough to prevent people from being logged in more than once. I would go with session strings, but I consider that a band-aid rather than a solution. Security is a cat-and-mouse game, so it's worth a shot until a better idea comes around. Passwords for user-authentication are like a band-aid, too, but we've been using those for 1000s of years.
I'm not an expert on persistent connections, but I believe those can be tricky too, if you're dealing with the right kind of hacker.