IP range validation about validation HOT 20 CLOSED

I like the constructor param, but don't like being the second. I believe this is possible:

v::ip(FILTER_FLAG_IPv4); //using a filter_input flag as it already does
v::ip('192.168.0.*'); //using the new range validation

We can distinguish them by the type. Filter flags are always integer and our range pattern is always string =) What do you guys think?

from validation.

+1

from validation.

This v::ip('192.168.0.*') looks interesting. +1.

from validation.

@drgomesp your're right =)

from validation.

@alganet and I talked a little bit on facebook about this trying to find the best way to code.
We said about using the Between rule - without the ip2long() - internally (just like Between and Domain does), but after some tests I found out that we really need to use that function:

var_dump('192.168.2.2' <= '192.168.2.255'); //true
var_dump('192.168.0.2' > '192.168.0.0'); //true
var_dump('192.168.2.6' >= '192.168.0.0' && '192.168.2.6' <= '192.168.2.255'); //false

var_dump(ip2long('192.168.2.2') <= ip2long('192.168.2.255')); //true
var_dump(ip2long('192.168.0.2') > ip2long('192.168.0.0')); //true
var_dump(ip2long('192.168.2.6') >= ip2long('192.168.0.0') && ip2long('192.168.2.6') <= ip2long('192.168.2.255')); //true

I'm implementing this right now and I'll send a PR soon ;)

from validation.

So, I think travis is broken, someone knows about it?

from validation.

We saw that, but something odd is happening. All tests passed before I commit =/
@alganet will remove the --testdox param on phpunit execution so we can see what's going on.

from validation.

Don't worry @lcobucci! Unfortunately is not the first time that PHPUnit trolling us.

from validation.

Any idea? https://travis-ci.org/Respect/Validation/jobs/4088431

//CC @augustohp, @alganet, @wesleyvicthor, @nickl-

from validation.

That helps.
The validation that I've coded will do the following things.

1. Calculate the min address by replacing * to 0
2. Calculate the max address by replacing * to 255
3. Assert that the long value of the address is between the long value of min and max addresses.

That lead us to this code:

var_dump(ip2long('10.168.2.6')); // int(178782726)
var_dump(ip2long('0.168.2.6')); // int(11010566)
var_dump(ip2long('255.168.2.6')); // int(4289200646)

var_dump(
    ip2long('10.168.2.6') >= ip2long('0.168.2.6')
    && ip2long('10.168.2.6') <= ip2long('255.168.2.6')
); // bool(true)

As I mentioned before the test suite is 100% here...

from validation.

I know man, really! Take a look:

• OSX: 100%;
• Fedora 17: "Segmentation fault (core dumped)" at test Respect\Validation\ValidatorTest::test_set_template_with_multiple_validators_should_use_template_as_full_message;
• Travis: Failure on "Respect\Validation\Rules\IpTest::test_ips_between_range_should_return_True with data set #5 ('10.168.2.6', '*.168.2.6')".

from validation.

Is this related, in any way, to #87?

from validation.

I think so, but PHPunit, XDebug and PHP don't decide of who is this bug, it is like a ping-pong game.

from validation.

Sad but true.

Sebastian Bergmann thinks this could be related to the zend distribution of PHP.

from validation.

I believe it's the integer size. We'll need to check for PHP_INT_MAX and use the bccomp function if the integer size sucks 32bits. 64bit should be fine though. Wonder what could have happend with IPv6 addresses =/

from validation.

@drgomesp The funny thing is this occurs with some frequency when running PHPUnit tests..

from validation.

Fixed on #105

from validation.

Waiting for Travis... today it's of screw <~ Brazilian joke detected.

from validation.

Bad translation detected.

from validation.

Stops-goods! You got it!

from validation.