Jump to content

All IP Addresses in Statistics Tab are Now Only My Website's!


traylor23

Recommended Posts

Weird. I just upgraded to 6.2.4 and since then, when I go to see who's on the site, it's me...like 100x! Every single visitor is shown with my website's IP address. While this isn't really a big issue, it is concerning given the amount of Russian bots I've had in the past. I've included a pic to show what I'm talking about!

 

IPWEIRD.jpg

Link to comment
Share on other sites

So, we are to infer that you are not the one who is scanning your site not sending back the cookies (to maintain session state)?

We would ask that you (somehow) examine logs that recorded the HTTP headers of these accesses.

In /includes/functions.inc.php, the function get_ip_address() works through various headers to find the most appropriate source of the visitor's IP address.

If your site uses some type of intermediary (a CDN -- Cloudfront, MaxCDN, Cloudflare?), there could be a string of IP addresses in the header. This function tries to find the correct one.

Maybe it is getting confused?

Link to comment
Share on other sites

I have no clue. There's no intermediary that I'm aware of. I posted a test link to Twitter. I know that every single click on that link is showing up as my website's IP address. The only visitor that is not my website's IP address is the record where I am logged into admin, which shows my device's IP address (different servers). Once again, it only started doing this after the update. It's not a big problem, just a curiosity.

Link to comment
Share on other sites

8 hours ago, havenswift-hosting said:

This is very unlikely to have anything to do with CubeCart but is almost certainly caused by a server level change done by your hosting company - likely some form of front end caching that they haven’t configured to correctly pass through the visitor IP address

Ian

That would make more sense! Any ideas on how to discuss with them a correction? While it isn't imperative I see who's on the site, it does help when weeding out spammy registrations, when they occur.

Link to comment
Share on other sites

18 hours ago, traylor23 said:

That would make more sense! Any ideas on how to discuss with them a correction? While it isn't imperative I see who's on the site, it does help when weeding out spammy registrations, when they occur.

Tell them what you have told us and that it used to work but no longer does and that you dont think it is the application.  They will know if they have done something major to the server that could have caused this - if they have made a change as significant as this and not told their users, it is extremely poor practice.

You need to know IP addresses of people signing up on your website to be able to prove GDPR compliance

Link to comment
Share on other sites

Were you able to solve this problem ? I have same problem since few weeks,made no upgrade,so it looks it is some problem with host/server.So just wondering if it was solved prior contacting my host provider.I checked my cpanel visotor´s log and there all ip addresses of visotors are correct and real ones.

Link to comment
Share on other sites

No solution as of yet. I did contact my host (Hostmonster/Bluehost), and I was told they would e-mail me a response to the issue. It's been 3 days since that contact, and nothing. Interesting that you're experiencing it, too. Who is your host?

Link to comment
Share on other sites

Cheap hosting companies will almost always blame an application for the problem, sometimes it is but mostly it isn't but they don’t have the expertise to know and actually have little interest or dont care anyway - pay peanuts .....

We have a large number of CubeCart sites hosted across multiple servers and all clients on our fully managed CubeCart plans (and many on the self managed plans ) are running 6.2.4 and none of these have the problem.

If either of you want to try your sites on our hosting then happy to move  them across and test

Link to comment
Share on other sites

Thanks for answer,I am at Hostgator,so I think it is same company now.I also contacted support,but they said,they have to forward it to some higher tech help.I noticed that all started after 7th March,prior this logs have correct ip addresses.Did you check yours ?

Link to comment
Share on other sites

Let's try to figure out what and where this is coming from.

In the file /includes/functions.inc.php, find:

function get_ip_address()

On every line that STARTS WITH:
$address =
(there will be eight statements)

At the end of each of those statements, add the following:

if(is_object($GLOBALS['debug']))$GLOBALS['debug']->debugMessage('The IP address found at line '.__LINE__.' and is: '.$address);

In admin, Store Settings, Advanced tab, enable debugging and enter your IP address in the next field (www.whatismyip.com). Clear Cache.

Request a page from the storefront. At the bottom of the page, there will be a long grey section of diagnostic data. At the bottom of that section, look for the Debug Messages: list.

Obviously, CubeCart will find your IP address, rightly or wrongly, but we would like to see the entire value for $address.

The line number is where CubeCart found some sort of value.

Link to comment
Share on other sites

Hello,should be this added as new line just bellow or right behind before ";" ??? I added it to every stament as you describe as new line,but no debugging is on.

            $address = $_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];
            if(is_object($GLOBALS['debug']))$GLOBALS['debug']->debugMessage('The IP address found at line '.__LINE__.' and is: '.$address);
 

I quickly enabled debugging not limited to my ip address and got this message:

PHP:
[Notice] /home2/minerals/public_html/store/includes/functions.inc.php:527 - Undefined index: X-Forwarded-For[Notice] /home2/minerals/public_html/store/includes/functions.inc.php:527 - Undefined index: X-Forwarded-For

and all 5 debug lines show my dedicated ip address

Debug Messages:
[0] The IP address found at line 547 and is: 198.57.148.64
[1] The IP address found at line 553 and is: 198.57.148.64
[2] The IP address found at line 558 and is: 198.57.148.64
[3] The IP address found at line 547 and is: 198.57.148.64
[4] The IP address found at line 553 and is: 198.57.148.64
[5] The IP address found at line 558 and is: 198.57.148.64

Link to comment
Share on other sites

Ok. Add the new code on the same line after the last semi-colon of the existing code on each line that STARTS WITH $address=. This way, the line number reported will be THAT LINE where $address gets its value from.

Not limiting the debugging to your address (according to www.whatismyip.com) means everyone will see the diagnostic section. You may not want world+dog to see that.

We see that there is only one IP address - as opposed to a series of IP addresses separated by a delimiter character. We now need to ask if that is the IP address of the server hosting your installation of CubeCart, or your local machine where you are accessing your store (according to www.whatismyip.com).

If the shown IP address is your hosting server's IP address, then the web server of your hosted environment is not passing to PHP the correct values for PHP's $_SERVER array. (In admin, PHP Info, look for a table named 'Apache Environment'. If there isn't one, then maybe your hosting web server isn't Apache. If there is, compare SERVER_ADDR with REMOTE_ADDR. Then go to the last table 'PHP Variables'. Compare _SERVER['SERVER_ADDR'] with _SERVER['REMOTE_ADDR'].)

 

Link to comment
Share on other sites

From what you have reported, I will assume you are running CubeCart of a version probably less than 6.2.3. (That is because the error message about line 527 means the functions file has not had its line numbers bollixed by PSR on versions 6.2.3+.) Or, at least, the functions.inc.php file has not been replaced by the new version.

Tracking line numbers then suggests that the web server is mis-reporting or mis-interpreting the IP address for the  X-Forwarded-For header. There may be a 'load balancer', router, firewall, or (most likely) a 'reverse proxy server' that is not communicating the remote (client's) IP address to the server running PHP.

When you say:
"Just had an order come in, and the customer's IP address??? You guessed it! Mine!"

Just to be clear, the IP address being logged is that of the server hosting your site - not "technically" Mine! for the purposes of this discussion.

The Mine! address, in my world, would be the IP address of the computer/LAN I am using to visit your site - being at home, at the office, using my mobile, etc. (according to www.whatismyip.com).

Here's the interesting consequence -- if CubeCart uses - for the Remote_Addr - the server address, then limiting the debugging to any address other than the server address would cause debugging not to show. But allowing the server address (being told that it is the Remote_Addr) would allow world+dog to see the diagnostic data!

Link to comment
Share on other sites

Hi,thanks for reply,I am running 6.1.15 and reported ip is website dedicated ip address.I just had no other chance than switching for a short time debugging,just to see variables.Other user who reported same problem is hosted at same provider,I am at hostgator,he at bluehost,so same company and I guess they changed probably some things on their servers.I reported this issue to hostgator,but as far got no response,they said they must escalate it to some higher level tech help.I was already long time considering to move away to other host,so maybe it is just necessary kick...

I just checked php environments and see,that server address is correct dedicated ip and remote address is listed correct my comp/lan ip.So a bit strange....Any idea what is than wrong ??? 

 

Link to comment
Share on other sites

Earlier, I said:

The line numbers shown indicates that CubeCart is using the 'X-Forwarded-For' header. This then suggests that the web server is mis-reporting or mis-interpreting the IP address in that X-Forwarded-For header.

So, we have verified that the SERVER_ADDR and REMOTE_ADDR is correct. It is the PHP function apache_request_headers() - line 523 - is where Cubecart is getting the value of the server address.

Conclusion: There is an appliance just ahead of the web server that is adding/mangling the X-Forwarded-For entry in the Request Headers HTTP stream with an erroneous value.

It is possible that this appliance (a reverse proxy server?) uses in a correct fashion the newer Forward header. See if Forward is in the two PHP Info tables discussed earlier.

Until the above gets sorted, you can implement a work-around:

In the function get_ip_address(), find:

	// Remove port if it exists
	$parts = explode(':',$address);
	$address = (empty($parts[0])) ? $address : $parts[0];

Change to:

	$address = $_SERVER['REMOTE_ADDR'];
	// Remove port if it exists
	$parts = explode(':',$address);
	$address = (empty($parts[0])) ? $address : $parts[0];

We will use the REMOTE_ADDR because we have verified in PHP Info that it is correct -- FOR YOU!

Link to comment
Share on other sites

Thank you,I changed this part of code.I decided to move to other host,so I hope it will be than solved.But your work-arround code works,so at least for now it is some solution to solve this issue for a moment.Thank you.I always appreciate your quick and helpful advices.David

Link to comment
Share on other sites

I want to update this issue.I just migrated to new hosting and there is no more problem with ip addreses,so it was obviously problem at my old host (Hostgator).I migrated to interserver,we host there already couple of years our other store running as cs-cart app.It looks,that also cubecart works much better,faster and no more errors.So thanks for this kick,it forced to me move away.Hostgator promissed to look in this issue and solve it,but as far I got no response anymore.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...