2

I was stuck with some validations for quite a while. I have been thoroughly searching the internet to find ways to apply the validations I require. I came across many methods for validations even certain Nuget packages. But in most cases my requirement was not fulfilled. I did a remote validation, which for me was the easiest to comprehend. But it did not give me the expected results in some cases.

I got suggestions from many asking me to do Client side validation using Jquery and leaving the Server side validation for the time being (Most of the advices were not pretty clear for me, I have never been to web development before). These languages being really difficult for me to understand, I had to keep on looking for ways to get my things done. Maybe I was in search of the easiest way to do a validation.

Finally I was successful in getting the desired output by validating my data in the controller Action method. I am not sure if it is a conventional method to follow or if I would end up with serious consequences at a later stage.

So now I am really wondering why nobody adviced me to do the validation in the action method when it is possible!! Is my approach right to do a valiadtion. Just for reference I am adding the validation that I have done.

   if (ModelState.IsValid)
   {
       if (db.SystemFamily.Any(x => x.FamilyName.Equals(systemFamily.FamilyName)))
       {
          ModelState.AddModelError("FamilyName", "Already exists");
          return View(systemFamily);
       }
       else
       {
          systemFamily.DateCreated = DateTime.Now;
          systemFamily.CreatedBy = User.Identity.Name;
          db.SystemFamily.Add(systemFamily);
          db.SaveChanges();
          return RedirectToAction("Index");
       }
   }

I am looking for flaws in my approach and the possible easiest alternative for my task.

Vini
  • 216
  • 1
  • 2
  • 12
  • 2
    [FluentValidation](https://github.com/JeremySkinner/FluentValidation) should do the trick, but software or tool recommendations are off topic, unfortunately. – Greg Burghardt Jun 28 '18 at 11:50

2 Answers2

1

Validation can be done in many different ways. Each way has its own drawbacks and benefits.

Frontend validation is very quick. It provides the best user experience, since you can provide immediate user feedback (even as they type). However, a clever user can alter their webpage to effectively change or disable the validation logic. This is not secure, but it is nice to use.

Backend validation is more secure. It ensures that no invalid data makes it through. No matter how much a clever user modifies their webpage, the data they send will be validated by the backend.
However, backend validation requires a roundtrip to the server. This means that the user might enter a form, submit it, wait for the page load, only to then realize that they made a mistake somewhere. This is secure, but it is not (as) nice to use.

The superior option is to have both validations at the same time. The frontend validation maximizes the user experience. The backend validation will usually pass since the frontend already prevents invalid values from being sent. However, if a clever hacker finds a way around the frontend's validation logic, then they are still stopped by the backend validaiton logic (which they cannot circumvent).
However, the drawback of doing so is that you're repeating yourself, and it will be more annoying to have to change two separate pieces of validation logic whenever something changes. If the two validation rulesets go out of sync, you will create a horrible user experience.

So, the question is what your two main priorities are:

  • Security + user experience : Use both validations. It won't be easy to develop or maintain.
  • Security + ease of development : Use backend validation. It won't have the best user experience.
  • User experience + ease of development : Use frontend validation. It won't be secure.

I would stay away from only using frontend validation, unless you are not worried about malicious usage of your website (e.g. an intranet application with no real responsibilities).

Flater
  • 44,596
  • 8
  • 88
  • 122
1

Technically it is possible to do validation almost anywhere. It is the purpose of the validation that determines where you should place it, and if you want a robust, user friendly site/app, then you may need all of the different types of validation.

To alert your users what type data they need to input, you need Front End Validation with some form of JavaScript. If you do not have Front End validation, the user will not realize there is a problem with their input until they submit the form, which is highly annoying for them and can cause state problems for you. JavaScript runs on the users browser so doing validation here lets you alert the user to problems as they fill out the data (password too short etc).

Because JavaScript runs on your user's PC however, that means you cannot trust it. Users can disable it, bypass it, or even hack it, which means you must have Server Side Validation as well to ensure the data is in the format you expect and can work with. There are many more ways to implement Server Side Validation.

Technically in MVC you can do some checking in the Action, but that is not necessarily the best place for it. For a lot of basic definitions (data type, min length etc), you should look into handling it in the Model instead. You are actually already checking ModelState.IsValid, so if you can define your validation in the Model, your code will already work. You might also have a class that has its own validation logic that you can interact with.

Another purpose of validation is for the data integrity of your database. This type of validation is best put into the database itself, or perhaps in the update procedures you may call. This may be the source of your confusion. If you are trying to prevent duplicate entries in your database, it would be best to make the FamilyName a key in the database, which will cause any attempts to insert a new row with the same FamilyName fail. You can then catch that exception and inform the user that it already exists, rather than preemptively check if the row already exists before trying to save to the database.

Nathanael
  • 827
  • 4
  • 11