Player IP Address's

[Crazy-T]

Hey,
Im stuck! I need a answer for user ip's what would be the best?.
There own ip table or storing them in the users table.
Will have 3 cols
#1 ip_register //signup ip..
#2 ip_last   //update everypage....
#3 ip_login  //update everylogin

Any ideas? thanks.

[Slashmore]

I'm not really sure, I would chuck them in with the users/players table to save a table but thats just me, I dunno if its best to have more smaller tables or few bigger tables for performance.

[Dasein Fiasco]

I think it's just fine to store that information in the users tables. If you go so far to extract it then you're probably modeling something more like an activity log, which just begs more questions. There is no design downside or extra work to storing the ip addresses in the user's table.

[Crazy-T]

Would this be a good idea or NO..
Store ips into text
Then its like this.
lastip;loginip;registerip; //comes from users table all in one.
$ip = explode(";", $user->ips);
echo <<<OUT
Last IP: {$ip[0]}<br />
Login IP: {$ip[1]}<br />
Register IP: {$ip[2]}<br />
OUT;

[karnedge]

register_IP will never change so it should be put into a MyISAM table that never changes for quick reference.

last_IP and login_IP are essentially the same in a sense unless you check back with the login_ip at some later point but that doesn't make any sense to me. If you are actually checking against the current IP to the last_IP at any given point and unless it's changed you don't need more than two.

Let's say, you logged in 1.1.1.1 and it keeps coming up the same at every page load. Then you decided to use your other computer you had already logged in with another IP from earlier today. The system at page load (including auto login using the session handler) would see the new IP, so it says to you "let's get your password again just in case this isn't some session stealing user", if it clears then you are kept logged in from both IPs, so then you would use the explode/implode function for more than one IP.

This of course is assuming your using sessions to keep your users logged in. By the way, I would only check the IP at major points in your game like if they were about to make a player trade or change settings or profile. That way it's that much less of a load on your system.

[Crazy-T]

Ahh - I see now Thanks!!!!
Well I'm still looking at other tutorials on the net, about storing the sessions in a database table.
Thanks again!

[Chris]

#2 ip_last   //update everypage....

What do you need it for? It seems like it is only causing an additional table write without any real benefit...

Make two user tables, one to store rarely used things (register_ip, email, password) and the playing table (all data that is used after you succesfully login to the game). Very convenient and fast.

[Crazy-T]

What do you need it for? It seems like it is only causing an additional table write without any real benefit...

Was thinking of something else, but yeah i got it wrong. lol

Make two user tables, one to store rarely used things (register_ip, email, password) and the playing table (all data that is used after you succesfully login to the game). Very convenient and fast.

Yeah, i was thinking of doing that, thanks for tip too.

[shoespeak]

Do you need two different fields for las_ip and login_ip? Why not just store the login_ip in the table. Then when they log in again, you check the current IP against the one stored in the database and if they are different, just print a message letting the player know this. Or if you are checking IP's as check for multis, this could flag the account and you could start logging every IP.

I just think most of the players will be logging in from the same IP every time...no need to store that data twice unless I am missing something...

[saljutin]

well depends on how their internet provider asigns IP to them...is it dynamical IP or static IP.
also people can login to game from work, school, internet cafe etc.
so then u can have quite a lot of "multies"

[shoespeak]

Yeah true I guess I didn't think about those people still using AOL...lol

[Nox]

Don't forget it can also be useful to a player to check if his/her account hasn't been accessed by someone unauthorized

I'm not sure I'll have signup IP, but I have a login log to register all log and ulog IPs and times...

"Last IP" would also be handy, but should you replace (and not just store) it on every pageload,
then almost every suspicious entry will be overwritten and lost before you find them out...
generally you will imho have a hard time working with just one value

I plan to log as much as I can, so far I use specificly designed tables but I didn't finish this really...
probably have also CRON regularly store logs into file and clean DB, but that's a minor, performance thing

[die4me]

i would just go with sign up ip and last login one

[codestryke]

For our games we use two fields in the player table register date/time and last login date/time.

Upon login we also take the ip and add it to a table called player_loginhistory. This allows us to see trends in when people login, times and what all IP's they used in the past. With just a couple fields in the player table you only get to see a snapshot of the last time they logged in and not a history of logins

[JGadrow]

I agree with codestryke. Logging is where it is at. In that manner, you can, with at least a measure of certainty, determine some information about a user. Is there only a single IP address? Then your user is accessing from a statically-assigned location. If there is NO common IP addresses they must have DHCP that is assigning an IP to them.

In the first case, you can identify possible shared account activity (some games prohibit this) or hacking attempt if, suddenly, records start appearing with a multitude of IP addresses.

[Karlos]

For our games we use two fields in the player table register date/time and last login date/time.

Upon login we also take the ip and add it to a table called player_loginhistory. This allows us to see trends in when people login, times and what all IP's they used in the past. With just a couple fields in the player table you only get to see a snapshot of the last time they logged in and not a history of logins

Very good idea, I'll have to use a system like that.