My Admin side has blocked my IP - HELP!

Remember I am on V4.6.3SP1

The solution that was provided which I used is this:

Edit the file: app/addons/access_restrictions/func.php
uncomment the following part of code of this func.php
if ($restricted && (AREA != 'A' || $acc_r['admin_reverse_ip_access'] != 'Y')) {
      die((!empty($restricted['reason']) ? $restricted['reason'] : __('text_ip_is_blocked')));
} elseif (!$restricted && $acc_r['admin_reverse_ip_access'] == 'Y' && AREA == 'A') {
      die(__('text_ips_denied'));
}

now comment out this part of the code

if ($ip['proxy']) {
    if (AREA == 'A' && $acc_r['admin_reverse_ip_access'] == 'Y') {
        $ip_condition = db_quote(' ip_from <= ?i AND ip_to >= ?i', $ip['proxy'], $ip['proxy']);
    } else {
        $ip_condition .= db_quote(' OR ip_from <= ?i AND ip_to >= ?i', $ip['proxy'], $ip['proxy']);
    }
}

Save the file and do a https://yourdomain.com/youradminurl.php?cc&ctpl

Remember I am on V4.6.3SP1

The solution that was provided which I used is this:

Edit the file: app/addons/access_restrictions/func.php

Thanks for the info but it did not make any difference. Still blocked. Even though I'm behind a WAF, the correct IP address is being used. This is so puzzling to me. I did not change any setting and this happened directly after one of the updates.

Thanks for the info but it did not make any difference. Still blocked. Even though I'm behind a WAF, the correct IP address is being used. This is so puzzling to me. I did not change any setting and this happened directly after one of the updates.

Thanks for the info but it did not make any difference. Still blocked. Even though I'm behind a WAF, the correct IP address is being used. This is so puzzling to me. I did not change any setting and this happened directly after one of the updates.

Did you get any feedback yet from the support desk at cs cart ?

Did you get any feedback yet from the support desk at cs cart ?

Thanks for asking. Support has been in touch but I think I found the issue. Waiting to see if they understand my explanation and can come up with a workaround.

I found out that PHP 5.6, on Windows, only supports 32 bit integers even if the platform, Apache, MySQL and PHP are all 64-bit. This is "fixed" in PHP7 but I have some scripts and other web apps that are not yet PHP7 compliant so I cannot upgrade at this time.

On 32-bit architectures, due to integer overflow, some IP addresses (not all) will result in negative integers when using ip2long().

What is puzzling me is the fact that the long integer form of my blocked IP address is correct when I view the entry in the database but if I upload a simple PHP file that converts the same IP address using ip2long(), I get a negative number. Presumably the MySQL database is properly converting the string representations.

I tried editing the code in app/addons/access_restrictions/func.php but I have been unsuccessful.

In my test file, if I use the following code...

echo ip2long($_SERVER['REMOTE_ADDR']);

... I get a negative number (integer overflow).

If I use the following code...

echo sprintf('%u', ip2long($_SERVER['REMOTE_ADDR']));

... the IP is correctly converted to a long integer which matches the number in the database. I just haven't been able to figure out how to apply this to app/addons/access_restrictions/func.php.

From the PHP manual:


The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). 64-bit platforms usually have a maximum value of about 9E18, except on Windows prior to PHP 7, where it was always 32 bit. PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, maximum value using the constant PHP_INT_MAX since PHP 5.0.5, and minimum value using the constant PHP_INT_MIN since PHP 7.0.0.

So it would appear that you can't cast it to an unsigned and that if you use Windoz prior to PHP 7, you are stuck with a signed 32 bit value.

CS-Cart Support basically said no support for Windows.

So it would appear that you can't cast it to an unsigned and that if you use Windoz prior to PHP 7, you are stuck with a signed 32 bit value.

I'm still not understanding why PHP can't be used to convert the number with...

sprintf('%u', ip2long($_SERVER['REMOTE_ADDR']));

... then compare that to the number in the database. The code above does convert the IP and it matches what's in the database :confused:

Oeps.. you are on a Windows platform ??

Oeps.. you are on a Windows platform ??

Since 2006.

How come I always feel like a toddler with poop in his diaper once I tell people I'm on a Windows platform? Everyone grimaces and stays clear :mrgreen:

How come I always feel like a toddler with poop in his diaper once I tell people I'm on a Windows platform? Everyone grimaces and stays clear :mrgreen:

Because it's like trying to put the square block in the round hole.?

In general, Windoz is built for an enterprise environment and is based around all other Windoz products (SQL Server, Active Directory, Sharepoint, Outlook, Office, etc.). There are so many little things that simply get in the way and add overhead and burden to the administration of a web-based application or service. It wasn't built for the web, it was built to serve as an internal server for MS based products inside a corporate firewall. Additionally, it's licensing costs can hold big surprises if you are ever audited by MS.

Yeah, I know. My previous post was meant to be rhetorical. Windows fills my needs just fine. I've self-hosted for more than a decade and I have only encountered a couple of small issues during that time period and I run several different scripts/web apps on different sites.

I will implement some PHP code and 2FA to secure the admin page until I can update to PHP7.

My thank you's to everyone :-)