Unexpected validation behavior

[ohtyap]

I know there are already a few issues about exactly this topic - so I didn't wanted to open a new issue and preferred to open a discussion here.

Given the following validation rule and data:

$rules = ['email' => 'email'];
$data = ['email' => '[email protected]']

$validator = Validator::make($data, $rules);

Less surprising, $validator->fails() tells us that everything is fine with the data.

But now take this example:

$rules = ['email' => 'email'];
$data = ['email' => '']

In this case, validation is passing => an empty string is a valid email address?

A few other examples that pass the validation:

$rules = ['some_string' => 'min:1'];
$data = ['some_string' => '']

$rules = ['an_option' => 'in:option1,option2'];
$data = ['an_option' => '']

Of course, with adding something like sometimes|required or filled these examples will work like expected. When looking at the code, I understand the situation on a technical level. But from a conceptional point of view, I expect that a given value is validated against the given rules without adding required or filled.
Moreover, adding these rules brings up another issue: Fields that contain null (even with the nullable rule) stop working, same goes for an empty array. But null and an empty array are valid values - like 0 or false.
Requirement of a field: An optional field, which can either be null or a string with minimum 5 characters and maximum 255 character

$rules = ['an_option' => 'nullable|min:5|max:255'];  // wont work, it is possible to pass an empty string

$rules = ['an_option' => 'required|nullable|min:5|max:255'];  // wont work, it is not optional anymore

$rules = ['an_option' => 'sometimes|required|nullable|min:5|max:255'];  // wont work, it can't be nullable anymore

$rules = ['an_option' => 'filled|nullable|min:5|max:255'];  // wont work, it can't be nullable anymore

$rules = ['an_option' => 'present|nullable|min:5|max:255'];  // wont work, it is possible to pass an empty string

As far as I understand, a lot of these behavior are coming from validating input coming from the request (with enabled middlewares like TrimStrings or ConvertEmptyStringsToNull ). And the behavior might make sense in these situations. But there are other scenarios - like validating data coming from an XML or CSV, from any external resource like a remote API.

It is possible to work around with all the things above - adding own (implicit) rules, not using the built-in required. But at the end, it is a work-arround for a very basic requirement of the validation system (and it should not be needed to add them yourself).

If there is a validation rule called email, the given value should get validated against the email validator. This is currently not happening with an empty string. Same goes for all other rules - in, min, max, date etc. (all none implicit rules) - an empty string bypass all these rules (unless required is given too).

Do you have similar experiences - or how dou you handle these things?

[newtonjob]

Well, the validation rules for those scenarios aren't passing, they are just not run at all.

See here https://laravel.com/docs/9.x/validation#implicit-rules

[ohtyap]

This is technically correct, and as already said, I understand why this issue happening. My question is more, how to handle this situation.

When using the validator, I expect the following to fail:

$rules = ['some_string' => 'min:1'];
$data = ['some_string' => '']

The validator is telling me, in this case, that the input is passing the validation. Whether rules are implicit or not is just implementation detail - the validation should fail IMHO.

[thinktrans]

While we are at it, may I also please request that, when you further develop the blocking rules for e-mails, please do take care of the internationalized e-mail addresses. They are new (not so new from technical implementation POV but more from the wider community acceptance POV) entrants on the block and the prominent software platforms need to be aware of their requirements.

If one is looking for rules for the mailbox from the perspective of the Internationalized Emails, follow the guidelines by the "Universal Acceptance Steering Group" - UASG-028

[newtonjob]

@ohtyap

If you're checking for min:1 then you most likely want to also have it required, like so required|min:1.

This concern only comes up when you're trying to validate an empty string or when the field is totally absent.

However, you typically will be sending data from a form post request or something similar, so the ConvertEmptyStringsToNull middleware will already convert any empty strings from the request to null.

So this will always fail:

$rules = ['some_string' => 'min:1'];
$data = ['some_string' => null]

Are you already aware of this behavior?

[ohtyap]

@newtonjob
Thanks for your reply.

However, you typically will be sending data from a form post request or something similar, so the ConvertEmptyStringsToNull

As I already mentioned in my initial question, ConvertEmptyStringsToNull might solve problems with the validation when you validate standard incoming post requests. But my question is explicitly about the validator as a standalone feature and not tied with the request flow (for validating data coming from external resources - not incoming POST requests).

If you're checking for min:1 then you most likely want to also have it required, like so required|min:1.

I disagree on this one. It is absolutely valid to have optional fields - and when optional fields are present, they should pass the given validation with the given rules. required, sometimes|required, filled are solving the issue with the empty string, but causing other errors: fields can't be nullable anymore or an empty array. (And yes, it is absolutely valid to have a required field that can be nullable - null is a valid value, same as false, 0 or whatever). See also my examples in the initial question.

This concern only comes up when you're trying to validate an empty string

This is true. The issue (as far as I know) is only about empty strings or strings containing only whitespace characters. But still, it shouldn't bypass the validation IMHO.

[JeremyWorkWork]

@ohtyap

Agreed. I just came across this issue using Spatie laraval-data package that uses the validator as a stand alone feature.

[julien-fontaine]

I agree that this behavior is not normal and have to change.

I encountered this issue in all the companies for which I worked. Developers were not aware of this behavior and did not expect it to work this way. This behavior is described in the documentation, but it does not have enough visibility.

From what I know, this was intended because in HTML forms, there is no difference between an unfilled input and one filled with an empty string. HTML forms send an empty string in both cases (for some input types), and so, there is no way in PHP to determine if the provided empty string was intentional or not.

If Laravel were to trigger validation when an empty string is provided, it would mean that users would have to fill out every input field in the form in order to send it, and there would be no optional input fields.

That being said, whether intentional or not, the input is still sent to the backend, and so, if an empty string is provided against the defined rules, the validator should not allow it.

The case of an optional input field sent without XHR is a very specific case. Instead of having strange behaviors with the validator and/or the ConvertEmptyStringsToNull method, I suggest adding a new rule, like ignore_empty_string, that developers can use to specify their intention. When this rule is present in the set of rules for an input, the validator will not try to validate it if an empty string is provided.

@ohtyap To answer your question, I typically use Laravel to develop APIs, and since I don't work with HTML forms, I use a composer patch to fix the validator.