I am using ASP.NET MVC3 with jQuery Validate + the unobtrusive validation support that comes with MVC3. Works great for almost everything, but I have one view where there is some view-wide validation that I need to do and I am not sure how to tap into the validation events that happen as part of MVC3+Validate+Unobtrusive. The actual validation will take just a few lines of code. I just don't know where to plug in that code.
I would like to tie into existing validation flow so that when the standard validation finds errors with individual fields and adds warning messages for them, my form-wide error message will also appear in the validation summary.
P.S. I am clear how to add appropriate model-level validation on the server side (Scott just blogged about it), but I feel it would be strange if some validation happened on the client and others only on the server. A user might see the client validation errors, fix them, then try to submit the form and only then get the model-level validation error message.
I would say what you are looking for is the new support for Remote Validation in Asp MVC3. Here is an article describing a common scenario, hopefully you can extend it yourself. Otherwise there are probably other articles around explaining it even better ;-)
http://www.aaronstannard.com/post/2010/12/07/remote-validation-asp-net-mvc3.aspx
/Victor
You should ALWAYS validate again on the server. Its really easy to circumvent javascript validation.
Rule #1 of Web Development: NEVER TRUST USER INPUT
What advantages, if any, does MVC jQuery Validation offer over the built-in MVC client validation?
I've used the built-in validation and am just curious as to if I'm missing anything or not.
How about customisation? I'm sure not everything is covered with the standard validators.
For example, our products are meant for people over 14yo so it's be nice to validate that client side rather than tie the server up with silly requests.
You can then share this and have a standard way of validating DOB.
MVC jQuery validation is done on the front end (client side), without submitting data to the controller (Server side). So it can save you some bandwidth/processing.
If you have a slow or overloaded server, users will get a quicker response to validation errors this way as well.
Server side validation is essential/required since it makes sure you are getting good data before you save it. The client side is nice to have, but shouldn't be all you have since its possible to bypass.
What's the best way to validate password and confirm password fields in a strongly-typed view?
Password Field Code:
<label for="BaseUser.PasswordHash">Password</label>
<%= Html.Password("BaseUser.PasswordHash", Model.BaseUser.PasswordHash)%>
<%= Html.ValidationMessage("BaseUser.PasswordHash", "*")%>
I don't know how to deal with confirm password field in mvc's way. Or just use javascript to validate?
This kind of UI validation rule might be done in the controller (contrary to my original answer). Download the Nerddinner.com source code, look at the AccountController.Register method where the ValidateRegistration method is called to see a specific example.
There's a complete walk through of the nerddinner.com site available as a FREE PDF download at http://tinyurl.com/aspnetmvc
but it doesn't go into the detail for your specific question in the walk through so just check out the source code as indicated above.
If you want to progressively enhance the user experience then you could layer the jquery validation plugin in the view to also validate client side.
Remember the danger with only performing the validation on the client via javascript is that all someone has to do is turn off javascript to avoid your business rules and bypass one layer of your "defense in depth" at stopping security attacks such XSS and Sql Injection.
I javascript is the way to go. If you want your validation routine on the server (what is it, anyways? standard mvc?) as well, then fine.
But why force a roundtrip for something as easy as "your passwords don't match". And if somebody wants to "hack" (e.g. turn off javascript) so that they can submit two passwords that don't match, then fine.
To do it on the server, you'd have two separate fields and if they don't match then you throw the error.
I am using AjaxSubmit to post a form and there are server side validations done using XVal (RuleException way). I am not using the try/catch way to add error to Model and then send to view. Instead - I want to use the HandleError attibute and in the OnException I am adding the errors to Model. The major problem is how do I get those errors as a results in the Ajax Call?
There is not a great solution built in right now. Doing this correctly requires a client-side validation framework (because, to display the errors, you need to dynamically change the HTML page), and until recently, ASP.NET MVC has not had that. However, ASP.NET MVC 2 Preview 2 introduced client-side validation, so it's reasonable to presume that something might be built into the framework soon.
In the meantime, however, HandleErrorAttribute won't help you. HandleErrorAttribute only knows how to redirect to an error page, which is generally not what you want to do in response to a server-side validation error even with a "normal" POST, and certainly not with an AJAX post.
There really two different scenarios you need to handle:
Validation errors are not catastrophic failures; they are simply bad user data, which you should expect. You just need to get the information back to the page, so that the page can be marked up to tell the user how to fix their data.
You also need to handle catastrophic failures, like unanticipated exceptions. This is akin to what HandleErrorAttribute does, insofar as you can display a message to a user, but you cannot necessarily match that message up with specific fields on your page.
To handle the first scenario of error, you need to wrap the model state up into an object which will be parsable in JavaScript code; JSON is the obvious fit here. You then need to have JavaScript code on the client side which parses this object and marks up the form fields. This is easier if you tie into an existing client-side validation framework, which already contains code for marking up form fields.
To handle the second type of error, you can extend HandleErrorAttribute in order to provide JSON instead of HTML in the event of a catastrophic failure. Again, you will need to write JavaScript code that will be executed in the event of a failure -- jQuery's global ajaxError event is useful here -- that detects this structured error information you've created and display some sort of useful message to the user.
If all this sounds a bit involved, well, it is, which is why it may make more sense to wait and see what will be built-in when MVC 2 is finally released.
Where do you put user input validation in a web form application?
View: JavaScript client side
Controller: Server side language (C#...)
Model: Database (stored procedures or dependencies)
I think there is validation required by each level:
Did the user input a sane value
are dates actual dates, are numbers actualy numbers ...
Do all of the checks in 1. again plus checks for malicious attacks(IE XSS or SQL injection)
The checks done in 1. are mainly to avoid a server round trip when the user makes a mistake.
Since they are done on the client side in javascript, you can't trust that they were run. Validating these values again will stop some malicious attacks.
Are dependencies met (ie. did the user add a comment to a valid question)
A good interface makes these very hard to violate. If something is caught here, something went very wrong.
[inspired by this response]
I check in all tiers, but I'd like to note a validation trick that I use.
I validate in the database layer, proper constraints on your model will provide automatic data integrity validation.
This is an art that seems to be lost on most web programmers.
Validation in the model, optionally automated routines in the UI that take their hints from the model and improve the user experience.
By automated routines I mean that there shouldn't be any per-model validation code in the user interface. If you have a library of validation methods, such as RoR's (which has methods like validates_presence_of :username) the controller or view should be able to read these and apply equivalent javascript (or whatever is convenient) methods.
That means you will have to duplicate the complete validation library in the ui, or at least provide a mapping if you use a preexisting one. But once that's done you won't have to write any validation logic outside the model.
Validation can be done at all layers.
Validating the input from a web form (all strings, casting to proper types, etc) is different from validating the input from a webservice, or XML file, etc. Each has its own special cases. You can create a Validator helper class of course, thus externalising the Validation and allowing it to be shared by views.
Then you have the DAO layer validation - is there enough data in the model to persist (to meet not null constraints, etc) and so on. You can even have check constraints in the database (is status in ('N', 'A', 'S', 'D') etc).
This is interesting. For the longest time I performed all validation in the model, right above what I would consider DAL (data access layer). My models are typically pattern'ed after table data gateway with a DAL providing the abstraction and low level API.
In side the TDG I would implement the business logic and validations, such as:
Is username empty
Is username > 30 characters
If record doesn't exist, return error
As my application grew in complexity I began to realize that much of the validation could be done on the client side, using JavaScript. So I refactored most of the validation logic into JS and cleanuped up my models.
Then I realized that server side validation (not filtering/escaping -- which I consider different) should probalby be done in the server as well and only client side as icing on the cake.
So back the validation logic went, when I realized again, that there was probably a distinct difference between INPUT validation/assertion and business rules/logic.
Basically if it can be done in the client side of the application (using JS) I consider this to be INPUT validation...if it MUST be done by the model (does this record already exist, etc?) then I would consider that business logic. Whats confusing is they both protecte the integrity of the data model.
If you dont' validate the length of a username then whats to stop people from creating a single character username?
I still have not entirely decided where to put that logic next, I think it really depends on what you favour more, thin controllers, heavy models, or visa-versa...
Controllers in my case tend to be far more application centric, whereas models if crafted carefully I can often reuse in "other" projects not just internally, so I prefer keeping models light weight and controllers on the heavier side.
What forces drive you in either direction are really personal opinion, requirements, experiences, etc...
Interesting subject :)
Validation must be done in the controller - it's the only place which assures safety and response.
Validation should be done in the view - it's the point of contact and will provide the best UE and save your server extra work.
Validation will be done on the model - but only for a certain core level of checks. Databases should always reflect appropriate constraints, but it's inefficient to let this stand for real validation, nor is it always possible for a database to determine valid input with simple constraints.
All validation should happen at least one time, and this should be in the middle tier, whether it be in your value objects (in the DDD sense, not to be confused with DTO's), or through the business object of the entity itself. Client side validation can occur to enhance user experience. I tend to not do client side validation, because I can just expose all of the things that are wrong on the form at once, but that's just my personal preference The database validation can occur to insure data integrity in case you screwed up the logic in the middle tier or back ended something.
I only do it in the View and Controller, the database enforces some of that by your data types and whatnot, but I'd rather it not get that far without me catching an error.
You pretty much answered your own question though, the important thing to know is that you can never trust the view, although that's the easiest route to give feedback to the user, so you need to sanitize on at least one more level.
Hmmmm, not sure. I would have said the Controller until I read this article re: skinny Controllers, fat Models
http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html
Since most of validations depends on business rules, I do the validation on the business layer as third party tool classes. There are other types of validations, such as user input, whereas it needs to be made in the controller, but you can encapsulate those validation rules in third party classes too. Really, it depends on what to validate.
The client side validations are the minor ones, just made to build a lightweight input validation, but the server side validation is required always. You never can trust in the user input ;)
.NET have nice controls to build validations, but the business layer always needs a better approach to validate the data and those controls are not enough to that task.
Simple input validation in the view. Full validation in the model. Reason? If you change your view technology, and the validation is in the view/controller, you have to rewrite your validation for the new view. This can introduce bugs. Put it in the model, and this is reused by all views...
But, as I said, simple validation in the view for speed and ease.