Rule 'digits_between' does not allow all valid numeric inputs

[Meeshalk]

Laravel Version

11.44.2

PHP Version

8.3

Database Driver & Version

MySQL 9.2.0

Description

I am using these following rules to validate a numbers, patch method;

'number' => [
      'nullable',
      'numeric',
      'digits_between:10,15',
],

The docs says The integer validation must have a length between... this is true for all digit related rules, like;

• digits
• digits_between
• max_digits
• min_digits

So, even if I want to validate a numeric input, Laravel is validating integer input.

Moreover:
All other size based validation on numeric inputs, tests the value and not the length.

Current Situation

So, there seems to have no option to validate length of a numeric input, it seems.

It would be very useful, if

These digit validations, takes into account the numeric or integer rule mentioned by dev and not overrides it to an integer under the hood.

framework/src/Illuminate/Validation/Rules/Numeric.php

Line 79 in b6a2af2

return $this->integer()->addRule('digits_between:'.$min.','.$max);

Can we not simply do;

public function digitsBetween(int $min, int $max): Numeric
{
    return $this->addRule('digits_between:'.$min.','.$max);
}

instead of,

public function digitsBetween(int $min, int $max): Numeric
{
    return $this->integer()->addRule('digits_between:'.$min.','.$max);
}

Furthermore according to PHP's docs;
This number gives true for both, is_int and is_numeric

var_dump(is_int(+913478344)) // bool(true)
var_dump(is_numeric(+913478344)) // bool(true)

Steps To Reproduce

'number' => [
      'nullable',
      'numeric',
      'digits_between:10,15',
],

This would not accept input like: +916035350000 this or any integer/numeric with +. And the error message is also kinda wrong.

[shaedrich]

While + is a valid prefix, a phone number is an unfortunate example, since a phone number is actually not really one number in the stricter sense

[Meeshalk]

@shaedrich Yes, a phone number is a bad example here (it could have spaces, brackets as well). However, this would be true for any numeric value with an +.

[shaedrich]

I was more referring this from a semantic standpoint. A phone number is nothing you would add or subtract for example. It's coincidentally only comprised of numbers without formatting but doesn't need to, that's probably just a technicality. And if it is "a" number then it's two or more numbers in a trench coat most of the time

[Meeshalk]

Updated!

[rodrigopedra]

Regarding considering the plus sign as part of an integer representation.

The unary + operator is the identity operator, and it implicitly converts its right-hand side value, to an integer or float as appropriate.

Reference: https://www.php.net/manual/en/language.operators.arithmetic.php

As such, one could say that this code:

var_dump(is_int(+913478344)) // bool(true)
var_dump(is_numeric(+913478344)) // bool(true)

It is first doing a conversion to an integer (using the + identity operator), and then checking with is_int() or is_numeric(). In such a case, the plus is not part of the integer representation.

On the other hand, the documentation for integer types, available at:

https://www.php.net/manual/en/language.types.integer.php

States:

The negation operator can be used to denote a negative int.

So although, the unary - is also an operator, it can be used to properly represent a negative integer. In that case, the minus sign is part of the integer representation.

[Meeshalk]

@rodrigopedra

Thanks for the explanation on unary +, good catch.

Even in the case with is_int and is_numeric casting the numbers to integer, result is still true. So, from Laravel's prospective +numeric or -numeric should still be treated as integer, right?

Furthermore, I investigated this a bit more and found that the error is consistent with -ve numbers as well.

I don't yet understand inner workings of Illuminate/Validation/, I'll soon look into it.

It seems like there is a itsy-bitsy 🐛 as PHP defines int;

An int is a number of the set ℤ = {..., -2, -1, 0, 1, 2, ...}.

Basic maths also tells us, 1 is actually +1, we just ignore the sign for convenience and this clearly also don't work with -ve numbers.

Even with just this as validation the error persists;

'number' => [
    'digits_between:10,15',
]

BTW, these works as expected; with both +ve and -ve signs.

'number' => [
    'integer',
]

'number' => [
    'numeric',
]

I think all the digit rules (mentioned in issue body) should support + & - signs. I am aware that digits and signs are different but we are validating a number, and both digits & sign makes a number.

[rodrigopedra]

As the docs says:

digits:value
The integer under validation must have an exact length of value.

digits_between:min,max
The integer validation must have a length between the given min and max.

References:

• https://laravel.com/docs/12.x/validation#rule-digits
• https://laravel.com/docs/12.x/validation#rule-digits-between

I would say your expectation is right, as the docs states: "The integer under validation" and not "A string composed of digits". (actually, one description is missing the word "under")

On the other hand, in the code, the comment on the corresponding methods can give an expectation of validating a string composed of digits, see:

framework/src/Illuminate/Validation/Concerns/ValidatesAttributes.php

Lines 681 to 695 in b6a2af2

	/**
	* Validate that an attribute has a given number of digits.
	*
	* @param string $attribute
	* @param mixed $value
	* @param array<int, int|string> $parameters
	* @return bool
	*/
	public function validateDigits($attribute, $value, $parameters)
	{
	$this->requireParameterCount(1, $parameters, 'digits');
	return ! preg_match('/[^0-9]/', $value)
	&& strlen((string) $value) == $parameters[0];
	}

and:

framework/src/Illuminate/Validation/Concerns/ValidatesAttributes.php

Lines 697 to 713 in b6a2af2

	/**
	* Validate that an attribute is between a given number of digits.
	*
	* @param string $attribute
	* @param mixed $value
	* @param array<int, int|string> $parameters
	* @return bool
	*/
	public function validateDigitsBetween($attribute, $value, $parameters)
	{
	$this->requireParameterCount(2, $parameters, 'digits_between');
	$length = strlen((string) $value);
	return ! preg_match('/[^0-9]/', $value)
	&& $length >= $parameters[0] && $length <= $parameters[1];
	}

The fix is simple, just changing both methods to use the filter_var() as in the validateInteger() method, instead of the preg_match().

I can send a PR, but I believe this would be considered a breaking change, as this validation rule is old, and some projects could be relying on the "string composed of digits" behavior and not be expecting for a leading sign.

Maybe the solution for the 12.x branch is to add a note on the docs stating it validate if the attributes only contain digits, and not imply it accepts any signed integer. Or to add yet another validation rule to account for signed integer lengths.

As a workaround, you can create a custom rule, or use the regex validator:

$validator = Validator::make([
    'number' => '+12345678901234',
], [
    'number' => [
        'nullable',
        'numeric',
        'regex:/^(\d{10,15}|[+-]\d{10,14})$/',
    ],
]);

dump($validator->passes()); // true

Custom rule sample:

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\ValidationRule;

class IntegerLengthBetween implements ValidationRule
{
    public function __construct(
        private readonly int $minLength,
        private readonly int $maxLength,
    ) {}

    public function validate(string $attribute, mixed $value, \Closure $fail): void
    {
        if (filter_var($value, FILTER_VALIDATE_INT) === false) {
            $fail('validation.integer')->translate();

            return;
        }

        $length = strlen(strval($value));

        if ($length < $this->minLength || $length > $this->maxLength) {
            $fail('validation.digits_between')->translate([
                'min' => $this->minLength,
                'max' => $this->maxLength,
            ]);
        }
    }
}

Usage:

$validator = Validator::make([
    'number' => '+12345678901234',
], [
    'number' => [
        'nullable',
        'numeric',
        new IntegerLengthBetween(10, 15),
    ],
]);

dump($validator->passes()); // true

[Meeshalk]

Thanks @rodrigopedra

I did implement a custom rule for my project, after that I reported this. Felt that this might solve few things.

My two cents;

1. Digits rules all 4 of them could be improved - I know breaking changes, but no one is in hurry for this. We could deprecate this in 12.x and remove in 13.x, with better rules or implementation.
2. For now let's just update the docs
3. We need something to validate length of numeric input (int, float)

Let me know, if a PR is needed for docs changes, or should I close this issue as is.

[rodrigopedra]

I am not a maintainer, but in my opinion, a PR to the docs is welcome.

You can also try sending a PR to master with the proposed changes.

[shaedrich]

We need something to validate length of numeric input (int, float)

Strictly speaking, a number doesn't have a length. Numeric strings have lengths. Numbers usually have places (integer, fraction ("decimal"), "significant").

[rodrigopedra]

You are correct @shaedrich. Thanks for the heads-up.

And that would be a great name for a potentially new rules: places, places_between, ...

EDIT: not sure if using "places" as the name of a rule would be correct, as places regarding a number does not include any signs nor decimal separators. A user might interpret the max size to not include an included sign.