Why does the default model binder not validate fields when they are not in form data?

Question

Hi,

Let's say you have simple object like this :

public class MyObject {
    public int Test { get; set; }
}

And you count on the default model binder to make sure the user does not leave the "Test" field empty when posting a form like below :

<form method="post" action="/test">
    <p>
        <%=Html.TextBox("Test") %>
        <%=Html.ValidationMessage("Test") %>
    </p>
    <input id="Submit1" type="submit" value="submit" />
 </form>

And this action :

[AcceptVerbs(HttpVerbs.Post)]
 public ActionResult Test(MyObject o) {
     return View();
 }

This all works as expected when the form data contains a key for "Test" (like "Test=val" or "Test=")

But if the key is not in the form data, then the validation doesn't occur. So in case of an empty post request or a request with a data like AnotherField=foo the property on the model object defaults to the type's default value (in this case 0). And ModelState.IsValid returns true.

This is, IMO, not the behaviour one would expect.
So what do you suggest to change this behaviour?

Edit : Keep in mind that a malicious user can just tamper the form data easily with FireBug or Tamper Data plugin to pass the default model binder's validations, which could cause some security problems.

Answer 1

You might consider using xVal to perform the necessary mix of client- and server-side validation. With it, you can add an attribute to your Test property dictating what sort of validation rules (required, regex validation, etc.) apply to it and then, with a little more work, get it to generate JavaScript rules for you as well as pretty easily perform model validation.

You're already aware that you're violating a rule of development - never trust client input. There's really no way around it.

Client-side validation (preventing a round trip to find out that there's an error) is nice-to-have, server-side validation verifying that things truly are in order is a must-have.

Answer 2

i hope its by design because I am about to start relying on this behavior!

in one instance i have two controls which post back the following fields :

ShippingAddress.FirstName
ShippingAddress.LastName
ShippingAddress.Line1
ShippingAddress.Line2

BillingAddress.Email
BillingAddress.FirstName
BillingAddress.LastName
BillingAddress.Line1
BillingAddress.Line2

Note: Billing Address does not have email displayed, even though the underlying model of course still has it

If I have Email as a [Required] data annotation in my model then it will only complain when it is missing from Billing Address.

But I definitely see your point! I'm just relying on it for this one scenario here!

Answer 3

After researching all the different ways to get the form values into my controller methods, I discovered that the "safest" was to explicitly define each form field as a parameter to the controller. A side effect is that if a form does NOT have one of the fields, it will throw an exception - which would solve your problem.

Answer 4

It is not validating the fields by design, unfortunately. Please take a look at this Codeplex issue that I've found and commented on.

It is really unfortunate, that MS has decided this is the correct behaviour for their model binder.

I believe the default model binder should validate the whole entity instead of just the posted data.