Programming advice :)

[Sparrow]

Hey guys, I need some advice on how to handle this situation..

I have a login connected to MySQL (C#) now the problem is I want to avoid having 2+ users login to the same account at once. I currently have a web server but that's it. So how should I go about making sure only one account is logged in at a time?

Should I send SQL statements every certain amount of time.. Should I somehow ping the user to make sure it is actually logged in etc etc..

Thanks for reading,
Daniel

 

[Taiga]

If you are using a server, then you can simply send a message to the client when the user is already loaded into the memory of the server, you can update an extra column that indicates that the user is already online in side the database.

If you are using just an application then you can insert an extra column with the name online. The only downside of this is that once your application closes unexpectedly then the user's account could get 'stuck' in an online state. (This way is not recommended.)

The best way to log multiple in at the same time is using a client to server model, If you can't use a server then pinging with big intervals is a good option but it will take a while for the user to 'time-out' if something goes wrong.

 

[Sparrow]

Yeah I was thinking this. For my application I don't want to necessarily keep it connected to a server. IS there any way I could do the same thing with a web server or not really?

 

[The General]

How about adding a column online (enum('0', '1')) to your users table.

Then when someone logs in you set it to 1 and when someone logs out set it to 0.

As you said you don't want to keep a persistent connection you can have the client application ping to the server every 10 seconds. Once the client hasn't pinged for like 20 seconds you can stop the session (perform garbage cleanup) and set the online to 0.

 

[s-p-n]

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):

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.

 

[Sparrow]

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):

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.

I actually did my solution similar to your random sessionString one, but the session string is an encrypted version of the user's external IP. It will check about every 30 seconds whether the database value of sessionString is the same as the encrypted version of their external ip. If they are different both users should be signed out.


Edit: Not sure how effective this will be long term but I guess in future I can do a client-server connection when I get a server.