PHP Fatal error: 1406:Data too long for column 'ip_address' at row 1

[mc12345678]

@mc12345678, the documentation for filter_val indicates that the options are either an array or a bitwise disjunction of values (as I supplied). I'll bite that all the default values should be used, so the change should be

 function zen_get_ip_address() {
    $ip = '';
    /**
     * resolve any proxies
     */
    if (isset($_SERVER)) {
      if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
        $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
      } elseif (isset($_SERVER['HTTP_CLIENT_IP'])) {
        $ip = $_SERVER['HTTP_CLIENT_IP'];
      } elseif (isset($_SERVER['HTTP_X_FORWARDED'])) {
        $ip = $_SERVER['HTTP_X_FORWARDED'];
      } elseif (isset($_SERVER['HTTP_X_CLUSTER_CLIENT_IP'])) {
        $ip = $_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];
      } elseif (isset($_SERVER['HTTP_FORWARDED_FOR'])) {
        $ip = $_SERVER['HTTP_FORWARDED_FOR'];
      } elseif (isset($_SERVER['HTTP_FORWARDED'])) {
        $ip = $_SERVER['HTTP_FORWARDED'];
      } else {
        $ip = $_SERVER['REMOTE_ADDR'];
      }
    }
    if (trim($ip) == '') {
      if (getenv('HTTP_X_FORWARDED_FOR')) {
        $ip = getenv('HTTP_X_FORWARDED_FOR');
      } elseif (getenv('HTTP_CLIENT_IP')) {
        $ip = getenv('HTTP_CLIENT_IP');
      } else {
        $ip = getenv('REMOTE_ADDR');
      }
    }

    /**
     * sanitize for validity as an IPv4 or IPv6 address
     */
    $ip = filter_var((string)$ip, FILTER_VALIDATE_IP);

    /**
     *  if it's not a valid IP address or still blank, set to a single dot
     */
    if ($ip === false || trim($ip) == '') $ip = '.';

    return $ip;
  }

Note also that your update 'lost' the check for $ip exactly equal to false, which is the filter_var return value and will result in a PHP Notice from trim since (bool)false is not a string.

If the default values are used, then yes the exact match to false is needed; however, in my final post after running a test and realizing that only three parameters were expected (eyes at one point thought saw four), I modified the default response to an empty quote which then wouldn't require the test for exactly false. If one or more of the additional filters were desired to be used, they could be added to the $options array as a 'filters' element. I did test in php 7.3 with strict mode to have the array in the filer_var call without issue, but the php manual implies that $options or some variable should be used rather than an array syntax.

[mvstudio]

Thank you both so much for the help!

I don't know what either modification does or how to test it at all, nor which one I should implement.
I guess for the time being I'll go with Lat9 suggestion and go from there.

In the eventuality something like this ever happens I get a client trying to break through, what would they actually see if they try inserting the same tactic during checkout? A warning message of some sort?

[mc12345678]

Thank you both so much for the help!

I don't know what either modification does or how to test it at all, nor which one I should implement.
I guess for the time being I'll go with Lat9 suggestion and go from there.

In the eventuality something like this ever happens I get a client trying to break through, what would they actually see if they try inserting the same tactic during checkout? A warning message of some sort?

Neither one is wrong, just different. I opted to seize control of what the default value would be and to not require modifying a second section of code which really should then just become

  if ($ip === false) {

as there no longer is a == '' response when using the current default settings of the filter_var function as reproposed.

As far as testing or knowing what would be seen, well, if able to use a development server (not your live active store), in the line before the use of the filter_var function (would suggest testing on the catalog side) you could add

$ip = 'e:21:DaabaeDe:3::2:fc:17:eeFac:0::21:000dcecadea:1::0a:2::0:9:ee:5::8:ae:20:DaabaeDe:0::8:feed:56:ded5DECEAAFac::eCfe:19:caceaefc:6:ae:5:caceb:1:11:caceca:20:DaabaeDe:0::1:4::13:000cecb:1';

Then could see as one navigates what the result is. In my minor navigation around my test site, I as a customer didn't really see any difference provided I didn't show the ip address information on the catalog side. Otherwise would likely need to look through the code to see if/where such information would otherwise be used.

[mvstudio]

Thank you! I truly appreciate it!

One more question. When the issue at hand took place, the order went through (sort of) but on our backend we couldn't approve or cancel the credit card at all because the transaction summary where the functionality for such is located, for some weird reason wouldn't even display. Would orders still go through in the same fashion? I would prefer if whoever is playing these games not be able to shop at all. Is that possible?

Thank you so much!

[delia]

This was happening in a 1.5.5f cart as well. I'm really curious what's causing this. Since the errors aren't seen on the website itself, this could be happening more often and the cart owners would never know it until the log folder gets too unwieldy.