It's easy to set our action not to validate the input just hooking up the attribute like
[HttpPost, ValidateInput(false)]
public ActionResult Signup(SignupModel model)
{
...
}
But I was wondering, is there a way to only do this in just one form field? and not all of them in the actual <form>
or, I have to use this and then worry about encoding properly all other fields?
You should not rely on ValidateInput to 'encode' your values. It doesn't encode values - it just rejects some values outright. And even if you use it, you still must encode all your values that are user-entered and displayed on the site in any way.
In fact, because of that - I've never used that validation myself. For example, if all I did was rely on that validation, people would not be able to enter some very basic things in forms like this one, such as trying to show example HTML.
But even the MSDN documentation and every book I've read said that the ASP.NET validation there does not protect you against every possible malicious input. So essentially, you can not rely on it to protect your users. You still must encode values you are displaying (and you should encode them only as you are displaying them, otherwise you'll end up with all sorts of display bugs where you've double-encoded things)
Using MVC3 , the attribute can be applied to Model by specifying SkipRequestValidation.
Related
I have a separate .dll with our database model and partial classes etc in using FluentValidation which works fine (it's to be used by both by desktop barcoding terminals and also by our website).
For the desktop apps I can read and display all errors like below
public override int SaveChanges()
{
var errors = this.GetValidationErrors();
if (errors.Any())
{
//handle validation errors
return 0;
}
else
{
return base.SaveChanges();
}
}
For the MVC site I can set up validators on individual models or create data annotations and get those working okay (which is not what I want). The thing I can't get my head around is how I can force my models to map to my entities in a way that I can display the fluent validation messages in the views. I don't want to have two separate sets of logic to be maintained and the barcoding apps and website must use the same.
Do I have to map my entities directly to the views? which i've been led to believe is a bad thing and not very flexible. Or is there a way of stating that a field in a model maps back to an attribute of one of my entities? perhaps an annotation of some description.
EDIT:
Just some clarification for the types of validation i'll need.
most front end input type validation will still stay in the viewModels (required/length/password matches etc - basically all the stuff I can use for client side validation as well). But there are all the business logic validations that I don't want there. Things like email addresses must be validated before other options can be set, account numbers must be of a particular format based on name (stuff I can't do with a regex). This particular date is not a valid delivery date etc.
I guess one thing I could do is add these to the ValidationSummary somehow and display them separate from the individual fields.
I think you're just looking at the situation wrong. What MVC is all about is a separation of concerns. There's things the database needs to know about that your views could care less, and vice versa. That's why the recommended practice is to use view model with your views and not the entity itself.
Validation is much the same. Something like the fact that a password confirmation needs to match the password the user entered does not concern the database at all. Or more appropriately, something like a validation on minimum amount of characters in the password does not concern the database, either; it will only ever receive a salted and hashed version of the password. Therefore it would be wrong to put this kind of validation on your entity. It belongs on the view model.
When I first started out using MVC, I used to add all the validation logic to my entity class and then go and repeat that same validation on my view model. Over time, I started to realize that very little of the validation actually needs to be on both. In fact, the largest majority of validation will should just go on your view model. It acts as a gatekeeper of sorts; if the data is good enough to get through your view model, it's good enough for your database. The types of validation that make sense on your entity is things like Required, but even that is really only necessary on a nullable field that must have a value by the time it gets to your database. Things like DateTimes are non-nullable by default, and EF is smart enough to make them non-nullable on the tables it creates by default. MaxLength is at times worthwhile if there should be a hard limit on the length of a text field in your database, but more often than not, nvarchars work just fine.
Anyways the point is that if you actually sit down and start evaluating the validation on your entity, you'll likely see that most of it is business logic that only applies to how your application works and not to how the data is represented at the database level. That's the key takeaway: on your entity, you only need the validation that's necessary for the database. And that's generally pretty thin.
Just an update. to get the two tier validation that i needed i had to mark all my entity model classes as IValidatable. Then i overrode the validate method for each class and invoked my fluent validation validator method there, passing back the errors needed. for the modelstate.addmodelerror i set the key as the field name and it mapped back okay. bit more code but it works. if i find a better way to do this ill update.
I'd rather not disable validation on my form. I feel like I'm not taking advantage of MVC's benefits if I do that. Is there a way to regex the contents of a property submitted in a form before mvc gets its hands on it? I simply want to allow only alphanumerical values and some symbols but still leave protection on. Do I have to disable with [ValidateInput(false)]??
You can create custom validation attributes and apply them to your entire model class, or individual properties.
http://odetocode.com/blogs/scott/archive/2011/02/21/custom-data-annotation-validator-part-i-server-code.aspx
I am looking for a way to dynamically specify the format of my model DateTime fields in the view. I need these to be editable (meaning I want changes to them to be properly bound to model on postback). I am not worried about validation as I will be using a jquery datepicker control on the resulting textboxes.
So far all I have found is a way of setting the format in data annotations in the model - which is way too static and restricting (unless there is also a way to modify data annotations at runtime?). Have also found guides for making templates for DateTime, but that is also static. Found some ways to format the fields in the view for "display only" requirements that won't post back changes.
So far the only thing I have come up is having a separate string field for each DateTime field in all my models, do conversion in controllers manually before displaying only the string fields, and then convert them back. Before I embark on his messy approach, does anyone have any suggestions for an easier/cleaner way?
You could technically write your own Annotation that will give you the dynamic format depending on your wants.
These are evaluated at runtime so depending on what you want to return you can do it then.
I am currently using attributes to return very specific data for specific uses.
Assuming you wanted to develop your Controllers so that you use a ViewModel to contain data for the Views you render, should all data be contained within the ViewModel? What conditions would it be ok to bypass the ViewModel?
The reason I ask is I'm in a position where some of the code is using ViewData and some is using the ViewModel. I want to distribute a set of guidelines in the team on when it's right to use the ViewData, and when it's just taking shortcuts. I would like opinions from other developers who have dealt with this so that I know my guidelines aren't just me being biased.
Just to further Fabian's comment; you can explicitly ensure viewdata is never used by following the steps outlined in this article. There's really no excuse not to use models for everything.
If you have no choice but to use ViewData (say on an existing project); at the very least use string constants to resolve the names to avoid using 'magic strings'. Something along the lines of: ViewData[ViewDataKeys.MyKey] = myvalue; Infact, I use this for just about anything that needs to be "string-based" (Session Keys, Cache Keys, VaryByCustom output cache keys, etc).
One approach you may wish to consider as your views become more complex, is to reserve the use of Models for input fields, and use ViewData to support anything else the View needs to render.
There are at least a couple of arguments to support this:
You have a master-page that requires some data to be present (e.g. something like the StackOverflow user information in the header). Applying a site-wide ActionFilter makes it easy to populate this information in ViewData after every action. To put it in model would require that every other Model in the site then inherit from a base Model (this may not seem bad initially, but it can become complicated quickly).
When you are validating a posted form, if there are validation errors you are probably going to want to rebind the model (with the invalid fields) back to the view and display validation messages. This is fine, as data in input fields is posted back and will be bound to the model, but what about any other data your view requires to be re-populated? (e.g. drop-down list values, information messages, etc) These will not be posted back, and it can become messy re-populating these onto the model "around" the posted-back input values. It is often simpler to have a method which populates the ViewData with the..view data.
In my experience I have found this approach works well.
And, in MVC3, the dynamic ViewModels means no more string-indexing!
I personally never use ViewData, everything goes through the Model, except when im testing something and i quickly need to be able to see the value on the view. Strongtyping!
In terms of ASP.NET MVC 2, ViewModel pattern is the preferred approach. The approach takes full advantage of compile time static type checking. This in combination with compiling mvc views will make your development work-flow much faster and more productive since errors are detected during build/compile time as opposed to run time.
I am displaying 3 or more versions of a form. One version is an edit form to edit all fields. A second version will be a read only version of the same form which will be used to show all the same fields but with all fields having readonly="true" on the client side so that the user cannot enter data. The readonly fields need to use a different css style. This is to display archived data. I am already hiding the submit button so they can't submit but I want the form to look like it is readonly. A third version will have some fields readonly and some editable for a particular class of users that has limited editing privileges.
I am using ASP.NET MVC 1.0. How do I modify all (or a subset) of the fields displayed so they are readonly. I would like to iterate through the collection of fields in the controller and set them all to readonly and also set the correct css class. I don't want to have to put an if statement on every field in the .aspx file (there are 40-50 fields) and I'd prefer not to have this on client side so I can prevent users from modifying javascript/html to edit things they are not supposed to.
TIA,
Steve Shier
Keep in mind that even if you set the tags as readonly on the server side, users can still change them through a variety of means, and whatever the value on the form is before it gets sent back to you.
Certainly the easiest way is client-side with jQuery:
$(function() {
$('input, select, textarea').attr('disabled', 'disabled');
});
Or, you could do it in your View, but it's ugly. Off the top of my head, you would need some sort of bool passed into the View (via ViewData I suppose), and check that on each Input to see if you should add the disabled attribute. Not my idea of fun...
I would have different views that correspond to your states and then choose the view depending on which state you are in. You could also implement it with partials, breaking down the pieces so that you can easily include editable or read-only versions of the different sets of elements. The read-only view, then, need not even include a form element. You could also present the data in spans, divs, or paragraphs rather than as input elements.
Note: you'll still have to check whether the current user has the ability to update/create data in the actions that process form submits. Just because you limit the ability to view data in a read-only format, that won't stop someone from crafting a form post to mimic your application if they want. You can't rely on hiding/disabling things on the client to prevent a malicious user from trying to enter/modify data.
I usually use partial views to represent forms and/or parts of forms.
I can think of two simple ways to do what you need (as I understood it):
<% Html.RenderPartial(the_right_partial, model); %> where the_right_partial is either a value passed from the controller or a helper (in which case, the_right_partial(something));
pass a bool or enum paramether from controller representing editability and then using a helper to obtain the right htmlAttributes, like:
<%= Html.TextBox("name", value, Html.TheRightHtmlAttributesFor(isReadableOrNot)) %>;
There may be other ways, like creating new helpers for input fields which accept an additional isReadableOrNot arg (but it seems an overkill to me), or like mangling the html/aspx in some odd (and totally unreadable/unmaintainable way), but I'd not suggest them.
Notice that using html attributes like disabled is client side, and with tools like firebug it takes just two seconds to change them.
Others have already said it, but I also have to: always assume that the user will do his/her best effort to do the worst possible thing, so check the user rights to modify stuff on server side, and consider client side checks as a courtesy to the user (to let her/him understand that the form is not supposed to be edited, in this case).
Since I am trying to use a single partial for the different states of the form, I am thinking I will create helper functions which will display correctly based on the state and the user. The helpers will use a dictionary of fields that will indicate under which condition the field is read only. I will still have server side checks to make sure data is valid and the user is authorized to make changes.
Thanks for all of your ideas and help.
Steve