I've just been reading the article on MSDN about remote validation. This is great, but it only shows validating a specific property value.
Is there a way I can pass other values from my model into the validation for a particular property? For example, let's say that a user wants to cancel a number of items off an order - they should be prevented from entering a figure greater than the original order amount.
Thanks
No, you can't.
Brad Wilson:
At this time, only property level
validators can emit client-side
validation (as that lines up much
better with the idea of input
validation in the form of the
browser... there is no "model" to
speak of, from the browser's point of
view).
Stuart Leeks:
I don't believe you can hook up client
validation with IValidatableObject
Well, i am nit sure if you mean this, but you can use AdditionalFields with your RemoteValidation attribute.
Remote Validation in ASP.Net MVC 3: How to use AdditionalFields in Action Method
Related
I hope someone can help me out to disable the default validation that MVC 3 runs when I post a string value in an integer field. Currently the application will add the error “the value ‘abc’ is not valid for IntergerProperty” to the ModelState before our validators are executed.
We don’t use client side validation and have our own validators that are loaded in the Global.asax. We only want to use these validators to check the input and would like to disable this check.
Is it possible to disable this behavior?
Thanks in advanced,
André
I think the best solution for your issue is to implement a custom model binder to override the default behavior if you really want/need to be able to take alpha chars in a numeric field.
The specific case I've got in mind is as follows: an AjaxFormComponentUpdatingBehavior("onchange") is added to a TextField in a form. The behavior verifies the text for certain conditions (either the model object or the form component model, doesn't matter), based on which it might display a message (or hide it, if it has already been shown).
The problem is, there are also validators added to the TextField. One of the possible (and likely) scenarios consists of the user typing in, first, a value that causes the message to be displayed by the AJAX request. If, then, he/she types in a value that doesn't pass validation, the message should disappear, but it does not.
Apparently, either the onUpdate() method for the AJAX behavior is not called at all, or I am failing in my attempts to insert a check for non-validated entries (I have tried to test for both null values and empty strings, to no avail; I have no idea what exactly Wicket's validators do to models when data is invalid).
I am wondering if someone who actually understands validators (or AJAX, actually) has any ideas on where the problem could be.
I can post edit and post code if someone tells me this is not a general issue tying validators and AJAX, but most likely a programming mistake. I still believe the former and thus I'll refrain from posting code sections, in order to keep the discussion on an API/theoretical frame.
Thanks.
When using an AjaxFormComponentUpdatingBehavior, if any of the IValidators fail their validation, onError() will be called instead of onUpdate(). Wicket will effectively prevent invalid user input from reaching the IModels in your components, so the component's ModelObject will not be changed at all. The invalid input will probably remain available by means of getInput()/getConvertedInput() (not sure if it will in an AJAX scenario, it sure is in a traditional form submission).
However, take into account that IFormValidators are not executed when using this mechanism. If you've got any, you might be interested in overriding getUpdateModel() so that AjaxFormComponentUpdatingBehavior will not bring maybe-invalid user input into your IModels, and set modelobjects manually when you're certain user input is valid.
Regarding your specific case, you could perform all the required logic in onError() (or rely on Models that will grab data from somewhere else), and just add the components that need refreshing to the AjaxRequestTarget. This is probably what's missing in your scenario.
Suppose I have a RadioButtonList control:
<asp:RadioButtonList ID="rdbSubscriptionType" runat="server">
<asp:ListItem Value="Eval" Selected="True">Evaluation</asp:ListItem>
<asp:ListItem Value="Monthly" Enabled="false">Monthly Subscription (not available yet)</asp:ListItem>
<asp:ListItem Value="Yearly" Enabled="false">Yearly Subscription </asp:ListItem>
</asp:RadioButtonList>
A malicious user can indeed submit to the server with a POST action a ListItem with Enabled = "false". I would like to forbid this behavior.
On server side I can simply check:
if( rdbSubscriptionType.SelectedItem.Enabled == true)
but I am not sure whether a malicious user can change the enabled status of the control also from client side, with Javascript or similar techniques. Is there any best practice to perform this validation?
You need to think about the business rules that suround the decision to make something "disabled".
If the only check you're doing is based on what comes back from the front end, you're in trouble. Anyone can use FireBug to change a html value and have it posted to the server.
In your serverside code, what business rule do you follow to determine if the user submitting the form is authorised to perform any given action?
You say in the html that they're not allowed to do a monthly subscription. On what business basis do you decide this? Once you're clear about that you can put it into code and check when the form is posted.
No, the .Enabled property can't be changed with JavaScript, you're fine with what you have (test this for yourself to confirm). That said, there is a more thorough way of setting this up:
Use a separate model to populate the rdbSubscriptionType items collection (enabled, value and display text), then on the server side, compare against that model, not against the asp:RadioButtonList control itself.
I've a small doubt. I use Spring SimpleFormController with a form backing object.
Let's say my formBackobject has the following member:
- Id
- Name
- Sex
on the jsp page, I only bind name and sex to input field. when i submit the form, the backend controller can remember the value of the id field and so can distinguish whether this is a "new" or "edit' mode.
Could you tell me the trick behind this?
Thanks,
In my opinion you need to override isEqual() and hashCode() function.
In my code I'm generating uuid and assign it to String and then implement isEqual() and hashCode() where I'm comparing these strings.
Such technique is very useful for Hibernate as well and it will assure you that you always generate unique object.
The 'trick' behind is that the form is kept in session. When you submit the form, only 'name' and 'sex' fields are overwritten and Id is left as it is.
It's logical to think that the id is saved in session. you're right. I don't submit the id value, but spring can auto load its value into the id field.
All this is done automatically behind the scene. And that's what caused my confusion since the first place.
Anyway, all of this are assumption made by you and me. It may not be true from the documentation.
A simple question: I have a Model-View-Controller setup, with Models accessing a SQL database. In which part should I sanitize/check for malformed incoming data?
It's important to keep error handling as low as possible in the stack, but supplemental in other parts. If you keep the sanitizing in the controller, you could break the model by swapping out the controller with a looser one, but you can never break the model by being strict higher up in the stack. Keep the sanitizing low in the stack for consistency, and high in the stack for user feedback.
I'd say the Controller should sanitize input.
The model should at most decline to store invalid data.
I would say it is the responsibility of the controller to validate the input and make sure the data is valid before passing on the data to the model.
If invalid data is found, the controller should redirect back to the view and display the relevant error messages.
Having validation in the view only could be bypassed if the user doesn't have javascript enabled or posts to the url directly, however some validation in the view is better from a user experience point of view since the user does not need to wait for a return from the server in a web application.
The model will validate business logic rules, i.e. password length requirements, if a user is allowed to perform an action or not.
The model should obviously also make sure interaction with the database is done in a safe way so that SQL Injection is not possible.
The controller should handle relaying business logic errors back to the view, but can also do some basic sanity checks, i.e. a field is not empty.
I would say output sanitization should also go in the Controller before being passed to the View.
I use two levels of checking. My controller will check what is supposed to be a date is a date, an int an int and so forth. Basically ensuring they can be used to set the values on my objects.
Then my domain has validation for things such as valid values and other business rules. These are ALWAYS checked before saving or interacting with an edited object.
All errors from either level get returned to the user so they can take remedial action as necessary.
I tend to:
Put syntactic validation in the view ("this field is numeric", "that field is a date"). This is often very easy or even implicit in your choice of view design (eg: using a date picker for date fields).
Put semantic violation in a separate validator class ("this date field has to be after that date field", "this can be null if that is greater than zero") and call the validator from the controller, passing errors back to the view for display.
(for my own pseudo-correct definitions of syntax and semantics...)