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.
... 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.
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.
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.