Jump to content

Recommended Posts

In my "create_member.php" script - from several months ago - I wrote this...

 

// Capture User's IP Address.
$ip = $_SERVER['REMOTE_ADDR'];

// Capture User's Hostname.
$hostName = gethostbyaddr($_SERVER['REMOTE_ADDR']);

 

 

And in my table, I have the field set as "Not Null".

 

 

I am wondering if I should change my code to account for if those Functions fail??

 

 

Would something like this be safer...

 

// Capture User's IP Address.
$ip = (isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : '');

// Capture User's Hostname.
$hostName = (isset(gethostbyaddr($_SERVER['REMOTE_ADDR'])) ? gethostbyaddr($_SERVER['REMOTE_ADDR']) : '');

 

 

Thanks,

 

 

Debbie

 

 

Link to comment
https://forums.phpfreaks.com/topic/264782-capturing-ip-and-hostname/
Share on other sites

requinix, $_SERVER['REMOTE_ADDR'] is not guaranteed to exist, even though if it works once (at some webserver) you can reasonably expect it to always work in the future.

 

Debbie, isset(gethostbyaddr($_SERVER['REMOTE_ADDR'])) is always true, for it always returns either a string or a boolean (FALSE when it fails). However it might prompt a Warning on malformed input (for example if you try to find hostname of "").

 

Perhaps you can use something like this

 

$ip = $hostName = "";

isset($_SERVER['REMOTE_ADDR']) && ($hostName = gethostbyaddr($ip = $_SERVER['REMOTE_ADDR']));

requinix, $_SERVER['REMOTE_ADDR'] is not guaranteed to exist

CGI dictates that the REMOTE_ADDR is always set. If it is not then either (a) it's not a CGI request, like through the command line or (b) whatever is invoking PHP isn't doing so according to standards.

As with pretty much everything, it depends. Spend a minute thinking about IP addresses, hostnames, and what you want to do with them, and decide whether you actually need to store the hostname ahead of time or whether you can put off looking it up until you need it later (if you do).

 

IMO the IP address is enough. I'd only store the hostname if you wanted to do a search on it. Like a wildcard search could be interesting but only if you actually care about doing it.

As with pretty much everything, it depends. Spend a minute thinking about IP addresses, hostnames, and what you want to do with them, and decide whether you actually need to store the hostname ahead of time or whether you can put off looking it up until you need it later (if you do).

 

IMO the IP address is enough. I'd only store the hostname if you wanted to do a search on it. Like a wildcard search could be interesting but only if you actually care about doing it.

 

Well, for my "logVisitor()" function, I don't suppose either is that important, but for my "create_member.php" script, I do want to know as much about the person as is reasonable determinable?!

 

And as I have time, I think I would ike to start building more "Tracking Features" to know the Who, What, Where, Why, and How of people visiting my website and their activity on my website...

 

The purpose of this inquiry, though, was mainly to make sure that I am error-handling properly so my code doesn't blow up?!

 

 

Debbie

Sounds like people's comments in the PHP Manual sort of advise against using gethostbyaddr().

 

I just remembered that one reason I wanted to capture IP and Hostname is for all of the Visitors visiting someone's Profile who do not have accounts on my site or aren't logged in.

 

It seems important to me to know that someone at 58.44.1.150 is constantly checking out one of my Member's Profile...

 

(Having the Hostname would just be a bonus.)

 

 

Debbie

 

Sounds like people's comments in the PHP Manual sort of advise against using gethostbyaddr().

 

I just remembered that one reason I wanted to capture IP and Hostname is for all of the Visitors visiting someone's Profile who do not have accounts on my site or aren't logged in.

 

It seems important to me to know that someone at 58.44.1.150 is constantly checking out one of my Member's Profile...

 

(Having the Hostname would just be a bonus.)

 

 

Debbie

 

 

I suggest using Google Analytics. There's no sense re-inventing the wheel.

all of that information should already be stored in your apache log files.  With the exception of hostname though.

 

I do agree with xyph though.  Google Analytics is where it's at.  They even have a feature now that will show you a live feed of who is doing what on your website... live!

all of that information should already be stored in your apache log files.  With the exception of hostname though.

 

I do agree with xyph though.  Google Analytics is where it's at.  They even have a feature now that will show you a live feed of who is doing what on your website... live!

 

Is that free?

 

I hooked up Google Analytics to my website about a year ago, and have personally NOT been that impressed.  (The Analytics package I pay for from GoDaddy is more informative than Google Analytics, or at least the free one I am using...)

 

 

Debbie

 

 

all of that information should already be stored in your apache log files.  With the exception of hostname though.

 

I do agree with xyph though.  Google Analytics is where it's at.  They even have a feature now that will show you a live feed of who is doing what on your website... live!

 

Is that free?

 

I hooked up Google Analytics to my website about a year ago, and have personally NOT been that impressed.  (The Analytics package I pay for from GoDaddy is more informative than Google Analytics, or at least the free one I am using...)

 

 

Debbie

 

 

 

Your host will always have access to more information than Google running it's scripts on your pages. They probably use the raw access logs.

 

Google Analytics is free, unless you want premium features. See

http://www.google.com/analytics/premium/index.html

 

Google Analytics is used by 57% of the 10,000 most popular websites (as ranked by Alexa Internet)

 

If you're not impressed, by all means, create your own solution. If your host is already logging these details though, I don't see why you need to collect it again in your scripts.

I hooked up Google Analytics to my website about a year ago, and have personally NOT been that impressed.  (The Analytics package I pay for from GoDaddy is more informative than Google Analytics, or at least the free one I am using...)

 

Your host will always have access to more information than Google running it's scripts on your pages. They probably use the raw access logs.

 

I don't have both in front of me, but what I like more about GoDaddy is that is tells me things like...

 

- Who visited my website

- Each visitors IP addy

- Time on Site

- Time on each Page

- Where they came from

- Keyword Search

 

 

The main thing I recall about the free Google Analytics I am using is all of this crap about Keyword Ranks and other stuff that makes no sense to me?!

 

If I used an image of a "Fuzzy Baby Chick" I don't care if the world is search for "Fuzzy Baby Chicks"?!

 

I care about people searching for Topics/Content on MY website.

 

I'm sure this is a much more complex topic than either of us are talking about, but at first impression, I personally think GoDaddy gives me more useful info for about $5/month.

 

 

Google Analytics is free, unless you want premium features. See

http://www.google.com/analytics/premium/index.html

 

I'll check that out after supper!

 

 

Google Analytics is used by 57% of the 10,000 most popular websites (as ranked by Alexa Internet)

 

Must be the "premium" one, because the free one is lame...

 

 

If you're not impressed, by all means, create your own solution. If your host is already logging these details though, I don't see why you need to collect it again in your scripts.

 

Well, the context of what started this was me wanting to track Who/What/Where for *security* reasons, and not for Marketing reasons.

 

I figure it can never hurt o capture a person's IP when they register or do other important things like send a PM or Checkout, but that is just me?!

 

 

Debbie

 

Google Analytics is free, unless you want premium features. See

http://www.google.com/analytics/premium/index.html

 

 

I looked at the link and it says this...

 

Premium $150,000 Annual Flat Fee

 

 

Care to spot me an extra $150,000??  ::)

 

 

Debbie

 

 

doubledee,

 

I've incorporated some of the security measures you're thinking about in one of my sites in the past, including elements like storing it in a SESSION and comparing it to ensure that it hasn't changed between sessions.  I've learned, however, that this doesn't really provide the level of security you want in a reliable fashion. 

 

For example, using my example of checking for a changing IP during the same session--it completely destoyed mobile access to the site (which was bad considering it was the trouble ticket system I wrote for my PC repair business and I had difficulties using it in the field with my phone!).  A phone moving from one "cell" to another can get reassigned an IP addess in no time flat, so just travelling down the Interstate can cause this check to flag the action and declare a "fail"

 

Additionally,while I can see your point about ensuring that someone from one IP checking one person's profile a large number of times would be cause for concern, there are a few things to think about here:

This check won't stop someone from using anonymizer (sp?) services.  One person can look like 20 unlogged people throughout the day because they constantly have a different address.  Additionally, have a chat with your lawyer.  One thing I've learned over time is that when you do something you aren't required to do, even when (maybe especially when), when the proverbial poop hits the fans, the suing attorneys will not say,"Well, at least you tried."  Instead, they'll say, "You intentionally set up a system so that you could flag occurances like that man stalking a single profile.  Yet he stalked that profile for three days before he killed my client's daugher and you did nothing about it, although you clearly had the ability to do something."  It sucks, and it's a shame, and I personally think it weakens society, but when you try to do take those extra non-required-by-law steps, it actually puts more of a legal burden on you, not less.

 

Also, based on the sound of this site, you should keep a sharp eye /ear out for recent developments on the individual state levels about social networking sites (especially dating sites) and state requirements about forcing registered sex offenders to announce themselves within the site and requiring the site owners to do background checks on its members.  Seems to me that if you're designing a site that would cause you pause enough to check if someone is stalking another member's profile, you might be affected by some of these laws that are currently being kicked around committees in different state houses. 

 

If you want to track IP, go into it knowing that there are very simple ways to defeat it and that any information you glean from it has to be taken with a grain of salt.  It can give you a general idea, but never anything with actionable specific detail. 

 

All of that to say my $.02 is: No, don't make it fail if you can't get that info. 

doubledee,

 

I've incorporated some of the security measures you're thinking about in one of my sites in the past, including elements like storing it in a SESSION and comparing it to ensure that it hasn't changed between sessions.  I've learned, however, that this doesn't really provide the level of security you want in a reliable fashion. 

 

For example, using my example of checking for a changing IP during the same session--it completely destoyed mobile access to the site (which was bad considering it was the trouble ticket system I wrote for my PC repair business and I had difficulties using it in the field with my phone!).  A phone moving from one "cell" to another can get reassigned an IP addess in no time flat, so just travelling down the Interstate can cause this check to flag the action and declare a "fail"

 

Additionally,while I can see your point about ensuring that someone from one IP checking one person's profile a large number of times would be cause for concern, there are a few things to think about here:

This check won't stop someone from using anonymizer (sp?) services.  One person can look like 20 unlogged people throughout the day because they constantly have a different address.  Additionally, have a chat with your lawyer.  One thing I've learned over time is that when you do something you aren't required to do, even when (maybe especially when), when the proverbial poop hits the fans, the suing attorneys will not say,"Well, at least you tried."  Instead, they'll say, "You intentionally set up a system so that you could flag occurances like that man stalking a single profile.  Yet he stalked that profile for three days before he killed my client's daugher and you did nothing about it, although you clearly had the ability to do something."  It sucks, and it's a shame, and I personally think it weakens society, but when you try to do take those extra non-required-by-law steps, it actually puts more of a legal burden on you, not less.

 

Also, based on the sound of this site, you should keep a sharp eye /ear out for recent developments on the individual state levels about social networking sites (especially dating sites) and state requirements about forcing registered sex offenders to announce themselves within the site and requiring the site owners to do background checks on its members.  Seems to me that if you're designing a site that would cause you pause enough to check if someone is stalking another member's profile, you might be affected by some of these laws that are currently being kicked around committees in different state houses. 

 

If you want to track IP, go into it knowing that there are very simple ways to defeat it and that any information you glean from it has to be taken with a grain of salt.  It can give you a general idea, but never anything with actionable specific detail. 

 

All of that to say my $.02 is: No, don't make it fail if you can't get that info.

 

jcanker,

 

Some interesting non PHP comments.

 

Thanks for your 2-cents!!

 

 

Debbie

 

 

As an analytics expert, you have a few options:

 

[*]Roll your own solution. IMO, forget about it.

[*]Use Google Analytics. It's free, and provides everything you want minus IP addresses. In reality, is there really a reason you want to know this?

[*]Use Piwik. It's an open source version of Google Analytics that you host. A plus, it's in PHP - so you can modify it to your needs.

[*]Use a server log parser, like AwStats

[*]Use a commercially available tracking system, such as WebTrends, Omniture SiteCatalyst, Coremetrics, etc.[/url]

 

The main thing I recall about the free Google Analytics I am using is all of this crap about Keyword Ranks and other stuff that makes no sense to me?!

Yes, because ranking is crap and completely useless. :facepalm:

 

Must be the "premium" one, because the free one is lame...

I call bullshit because it works fine for a lot of my clients.

 

Well, the context of what started this was me wanting to track Who/What/Where for *security* reasons, and not for Marketing reasons.

What sort of security are you going to get out of it, that you can't get out of server logs? And yes, you should be using analytics for marketing reasons (really just for business reasons.) You can make a lot of smart decisions based off of the data these tools provide to increase traffic, user experience levels (and thus happiness levels) and ultimately revenue.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.