Originally Posted by
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?
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
Code:
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
Code:
$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.
Bookmarks