Closed alariva closed 5 years ago
We're having this problem at the moment - is there any indication when it can be fixed?
Hi @OwenMelbz this is a temporary fork with this fix until PR is merged or issue gets addressed:
https://github.com/alariva/firewall
Regards,
Sorry for the delay, guys, just tagged v2.2.2 with it.
@antonioribeiro Hey
Now that has been fixed, it seems to have kicked the errors down the road a little!
It seems that there's loads of routes into the... vendor/pragmarx/support/src/IpAddress.php
file.
Including all the CIDR functions.
Every method in there also triggers notices or warnings e.g.
Additionally code that looks like
$cidr = explode('/', $cidr);
$range[0] = long2ip((ip2long($cidr[0])) & ((-1 << (32 - (int)$cidr[1]))));
$range[1] = long2ip((ip2long($cidr[0])) + pow(2, (32 - (int)$cidr[1])) - 1);
If the Ip that gets passed in just looks like 127.0.0.1
then exploding it means that $cidr[1] doesnt exist so throws more errors
@antonioribeiro sorry for chasing, we're also being chased :D do you know if there would be any movement on this?
Many thanks :)
When not guarded, a filepath string may be sent to
SupportIpAddress::ipV4Valid()
, finally reachinginet_pton()
, which will throw aE_WARNING: inet_pton():: inet_pton(): Unrecognized address <filepath>
This patch checks for possible valid filepaths while not hitting IO. If the string is a filepath it makes no sense to go on validating for IP format. Result is earlier validation return and avoid of exception report flooding on false alarm.
See https://github.com/antonioribeiro/firewall/issues/113