Form Validation validating blank values with min_length and valid_email rules

Hahah, thank you!

For an API it can makes sense, I think.

Yes, only will have rules for existing database fields.

Extra fields sent by a client is removed with unset.

The validation will be dynamically according to the input request.

All the allowed db table fields will be validated.

This is not just for a HTML form, but to general insert/update requests.

For example:

Having a table with 12 fields. When the client need to update the 'city' field he will not need to send all the 12 fields, but only a simple city field. And the validation must works on this field.

Of course, an authentication will be run before this.

Perhaps this is a really bizzare thing. Or I just not had explained more. It's that my issue is with the Form Validation that accepts blank values. I believe that something could be done about it.

Thank you, Mr. Narf.

 natanfelles.github.io

It's not a "fail", whatever you mean by that.

I don't understand why you'd have to validate again all the fields?

Fail because the Validation accepts a blank value as a valid_email or when we have a min_length[1] rule.

Fail because '' is not a Valid Email and '' have 0 length.

I said that I would need to validate again because Form Validation would fail by accepting blank values.

 natanfelles.github.io

If a field is required, then you have to fill it in. If it is not, you do not have to.

If you have an email field, that is not required, and the user does not fill it in, then it should not fail the validation, even if the validation says min_length 50, valid email, or whatever. It is not required, so no input is a pass.

With your city field example above, if I had a user presented with 12 possible fields that could be updated, you would prefill this with the existing data, and if he saved the form, all the possible fields that could have been updated, are updated. You might test to see if the field had changed but why bother, just update all 12.

Suppose a user had an email, but now blanked it out, if you do not update blank fields, how do you know the user wanted to remove his email address?

I would normally do this by the user selecting exactly what field he wanted to update. Say he chose his email address, then only the email address input is displayed, prefilled, for him to update. If he emptied it and pressed save, the field (assuming it is not required) would be updated to blank or null.

But, if the form validation does not work the way you want it to, you customise it to suit (which might be ill advised) or just do your own validation with a regex and some issets and whatever else you wanted.

Paul.

Hello, Paul. Thanks for reply.

If a field is required, then you have to fill it in. If it is not, you do not have to.

Ok. Only the required fields have the 'required' rule.

If you have an email field, that is not required, and the user does not fill it in, then it should not fail the validation, even if the validation says min_length 50, valid email, or whatever. It is not required, so no input is a pass.

Here are the "fail". If the user do not send a field that is not required, then this field is not validated (of course, and it is happening in the current Form Validation). But, if the user send a field with blank value the validation pass. Look, the field is set with '', a blank string. And the validation accept it as a valid email, min lenght, or whatever. This is a fail. A blank string is not a valid email!

With your city field example above, if I had a user presented with 12 possible fields that could be updated, you would prefill this with the existing data, and if he saved the form, all the possible fields that could have been updated, are updated. You might test to see if the field had changed but why bother, just update all 12.

Suppose a user had an email, but now blanked it out, if you do not update blank fields, how do you know the user wanted to remove his email address?

No. It's not possible "prefil" the resquest. I need only the necessary data. If the user send only the email, he could not to empty this value. Because the API need a Valid Email. If he want to update the email he need to send a valid email. Blank values are not accepted in the email and because of this, in the insert action (registration) the email was required. But on the update it is not required. But, if sent, he MUST send a valid email, blank string is not a valid email.

If blanks values was accepted, then would not be necessary define a validation rule with min_length[1]. It's obvious that  a blank string have 0 length and that the validation never could accept this!

I would normally do this by the user selecting exactly what field he wanted to update. Say he chose his email address, then only the email address input is displayed, prefilled, for him to update. If he emptied it and pressed save, the field (assuming it is not required) would be updated to blank or null.

Ok. But this is not just for HTML Forms. The validation is for REST. POST, PUT and PATCH methods.

But, if the form validation does not work the way you want it to, you customise it to suit (which might be ill advised) or just do your own validation with a regex and some issets and whatever else you wanted.

Yes. A simple way to customize this was adding a check if the input field have blank string or not. Then I added a 'isset' rule and is working fine.

---

The fact is that the name of the library is Form Validation and not just Validation. I'm using it out of a form.

But what I noted is that blank values are accepted when we have rules requiring something that is not blank.

If is said "we need a valid email" and the user send a blank value, it is not a valid email then the Validation MUST say it.

If is said "we need  min 5 characters " and the user send a blank value, it do not have 5 chars then the Validation MUST say it.

If the field is not required the user do not need send it. But if he sent, then the validation MUST works. And this is not occuring at the moment if the user send blank values. That way the client can fool the system and zero all its fields. The rules that are there, will serve no purpose.

 natanfelles.github.io

Look, all forms that do not have rules with the "required" rule can be cracked. The developer could set a super regex to do your validation rule, but if the user send only '', boom! The validation will pass.

 natanfelles.github.io

'required', 'isset' and 'matches'

https://github.com/bcit-ci/CodeIgniter/b...n.php#L704

 natanfelles.github.io

It's not a "fail", whatever you mean by that.

I don't understand why you'd have to validate again all the fields?

Fail because the Validation accepts a blank value as a valid_email or when we have a min_length[1] rule.

Fail because '' is not a Valid Email and '' have 0 length.

I said that I would need to validate again because Form Validation would fail by accepting blank values.

I don't need a translation of the word "fail", I know what it means.
What you mean to say with it in this context is an entirely different story - you want the library to work in a way that it was not intended to, and you're just saying "fail" because you're not happy with that. Per the rules it was designed to work with, it does not fail in any way.

If you have an email field, that is not required, and the user does not fill it in, then it should not fail the validation, even if the validation says min_length 50, valid email, or whatever. It is not required, so no input is a pass.

Here are the "fail". If the user do not send a field that is not required, then this field is not validated (of course, and it is happening in the current Form Validation). But, if the user send a field with blank value the validation pass. Look, the field is set with '', a blank string. And the validation accept it as a valid email, min lenght, or whatever. This is a fail. A blank string is not a valid email!

No, it doesn't accept it as a valid email. It accepts an optional field that was never filled, because that's what "optional" means.

If blanks values was accepted, then would not be necessary define a validation rule with min_length[1]. It's obvious that  a blank string have 0 length and that the validation never could accept this!

No, it is obvious that you refuse to accept that this is a form validation library.
A form has a pre-defined set of fields, which you choose to fill or not. If you don't fill one, it gets sent as an empty string.

Imagine a typical profile update form on a web page, where there's often a "password" and "repeat_password" pair of fields, that are optional, because you don't want to change your password every time you update your profile.
One would possibly define a min_length[8] rule for the "password" field, but that cannot mean the validation shouldn't pass if you don't always send a password.

I would normally do this by the user selecting exactly what field he wanted to update. Say he chose his email address, then only the email address input is displayed, prefilled, for him to update. If he emptied it and pressed save, the field (assuming it is not required) would be updated to blank or null.

Ok. But this is not just for HTML Forms. The validation is for REST. POST, PUT and PATCH methods.

This is exactly where you're wrong.

The library is aptly named "Form Validation", for a reason. It is only intended for HTML forms. Arbitrary HTTP requests are way outside of its scope.

But, if the form validation does not work the way you want it to, you customise it to suit (which might be ill advised) or just do your own validation with a regex and some issets and whatever else you wanted.

Yes. A simple way to customize this was adding a check if the input field have blank string or not. Then I added a 'isset' rule and is working fine.

You may as well only define the rules if the field is being sent - that's both easier and more logical in your case.
Still incorrect usage of the library though, and you will encounter other issues when you misuse tools.

The fact is that the name of the library is Form Validation and not just Validation. I'm using it out of a form.

The fact that you have a form somewhere doesn't mean you're using the library as intended. That's just confirmation bias.

But what I noted is that blank values are accepted when we have rules requiring something that is not blank.

If is said "we need a valid email" and the user send a blank value, it is not a valid email then the Validation MUST say it.

If is said "we need  min 5 characters " and the user send a blank value, it do not have 5 chars then the Validation MUST say it.

If the field is not required the user do not need send it. But if he sent, then the validation MUST works. And this is not occuring at the moment if the user send blank values. That way the client can fool the system and zero all its fields. The rules that are there, will serve no purpose.

Again, only the "required" rule makes fields required.

If a field is defined in your rules, it must be defined in the form. If it is not defined in the form, then the form is incomplete. Thus, your assertion that an optional field doesn't need to be sent is false.

There's no fooling the system; you're simply using the system for the wrong purpose.

Look, all forms that do not have rules with the "required" rule can be cracked. The developer could set a super regex to do your validation rule, but if the user send only '', boom! The validation will pass.

No, the form cannot be "cracked". You're just being the landlord here.

Haha. Yes.

Very thanks for your time explaining about.

This night I tested other frameworks and I see that both do the same.

I was thinking wrong about that.

 natanfelles.github.io