0

I have a guest book form created using asp.net mvc. The valid gender form field must be filled in by selecting a value from a drop down control. The drop down control has 3 options, i.e., "--Select--", "Female", "Male" and the "--Select--" is selected by default. The data model has been setup to force the visitor select either female or male but not "--Select--".

We know that the visitor has a chance to temper the form data, so he can submit the gender form field pointing to a value that does not exist in the database.

My question is:

  1. Can DataAnnotation prevent the user from posting a form field that does not exist in a database?
  2. What is the preferred approach to counter this attempt? Do I have to check the submitted gender form field first before invoking SaveChanges()?
Second Person Shooter
  • 14,188
  • 21
  • 90
  • 165

2 Answers2

1

It depends whether you need to provide the user with a specific error, or a clean validation message. In cases where the user is trying to tamper with the form post, I would not be too concerned about the user experience.

If you care about this, you can use the IValidatableObject interface to perform a validation against the legal values:

public class Person : IValidatableObject
{
    public string Gender { get; set; }

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        //ValidGenders is a list of valid values, retrieved from the database
        if (!ValidGenders.Contains(Gender))
        { 
            yield return new ValidationResult("Gender is not valid", new string[] { "Gender" });
        }
    }
}

The Model validation performs validation using IValidatableObject just as it does using data annotation validation.

On the other hand, if you don't care about the user experience, you could let the error happen in the database, and handle the issue using your standard error handling pipeline. Assuming your foreign key constraints are in place, the operation will fail because the Gender value is not found in the Genders table, or whatever your setup may be.

jevakallio
  • 35,324
  • 3
  • 105
  • 112
  • which is "cheaper"? Validating the posted gender against the lookup table in a database followed by throwing an exception manually if the validation fails or letting the database throw the exception ? – Second Person Shooter Feb 15 '11 at 09:01
  • 1
    @Recycle Bin: In cases when the gender is indeed invalid, validating on the web server is probably cheaper in terms of performance, because you avoid a database call and the exception overhead. But for every instance of form tampering, you'll have a "million" valid posts you end up validating, which also adds up. If you measure the cost in developer time instead of processor time, letting database do the validation is of course cheaper. I'm assuming Gender is not the only field you have to validate in this manner, so you'll end up writing a lot of boilerplate validation code in the long run. – jevakallio Feb 15 '11 at 09:06
0

Not sure if you are using any form of DTO's or Business Objects, but As well as validating the object client side (or within MVC) it may be worth having your objects validate themselves also.

This way you can catch any issues before they hit the DB. An interesting post on SO about the topic can be found here: Should Business Objects or Entities be Self-Validated?

Community
  • 1
  • 1
Cragly
  • 3,554
  • 9
  • 45
  • 59