I'm finding it hard to find out helpful information about ASP.NET MVC's validation HTML helpers - Html.Validate and Html.ValidateFor.
Has anyone worked with these methods? what are they for?
see this post for an answer
If there are situations where you
don't actually want a validation
message to visually appear for each
field (i.e. by using
Html.ValidationMessage), but would
rather allow a summary to be the sole
source of validation error messages
(i.e. by using
Html.ValidationSummary), you still
need some way to "trigger" the
validation to occur for the specific
fields you want it to.
This can be achieved by using the
Html.Validate/Html.ValidateFor<>
methods within your view. Those
helpers won't render anything, but
will simply register the specified
field for client-side validation.
Related
I am trying to find out what is the best approach for my task:
Create a form with validation, spamcheck etc. using existing functionality. The results of the form must be handled in an extension and sent to an external application via REST api. Additionally, an email should be sent.
I am still struggling with TYPO3 and would like some help for what might be a good approach. I would like to use existing functionality as much as possible and not reinvent the wheel.
there is the ext:form framework. I saw that there are finishers, but not that it might be possible to send the results of the form to a Controller action
if that is not possible, is it possible for my extension to get notified (e.g. signal / slot) when a form has been submitted
alternatively, I could use Fluid form ViewHelpers. I did not find much information about how to handle the validation
form.validationResults : I don't exactly understand what it does.
handle validation via JavaScript
Any pointers are appreciated.
I'm finding it hard to determine best practice for detecting duplicate form submissions. I'm using the latest SpringBoot, Thymeleaf and Spring-Security and the out-of the-box CSRF functionality all appears to be working.
The design of the application is such that submit buttons get disabled via JavaScript onclick, successful POSTs result in a redirect (POST->Redirect->Get pattern) and I had (seemingly wrongly) thought that the CSRF protection would provide the server-side protection for anything that slipped through the JavaScript.
For some reason my dodgy Logitech G500 mouse (which has started double-clicking everything) has managed to highlight a problem with the application. Somehow it has defeated the JavaScript and it has revealed that there is no protection on the server for duplicate form submissions - i.e. the form got processed twice. I'll have a look into the JavaScript later, but I don't want to rely upon this to protect the server so I want to be able to detect it at the server.
Given how much Spring does (including the CSRF protection) I was somewhat surprised and have done a lot of Googling. From what I can tell, there used to be something in the old Spring framework (references to AbstractFormController.handleInvalidSubmit) but that no longer exists now. I've also seen references to RequestMappingHandlerAdapter and settings such as synchronizeSession and sessionForm, but I don't really understand them yet. There are also a load of custom solutions that people have produced, including a HandlerInterceptorAdapter with associated tag library and a cache that performs some custom processing.
So my questions are:
Why doesn't the CSRF protection prevent this?
What sort of support is built in to detect and handle duplicate form submission?
If a custom solution is necessary, do you have any advice for best practice? In particular, the second click will get rejected
and if I display an error page the user might never see the handling
of the first click and thus not realise it was actually processed
directly.
I have read this: Duplicate form submission in Spring , including the Synchronizer piece from 2009 but of course it's quite old and some of those things are no longer valid.
Thanks
Marcus
My application currently makes massive use of hidden inputs such as:
<input type="hidden" name="id" value="123456"/>
For instance, using the above hidden input I can keep the id/pk of my object without displaying it to the end user.
I feel this goes against the principles of REST and I would like to know whether using a PUT url such as:
/advertisement/childminder/123456/edit
and doing away with the hidden input altogether might not be a better idea...
Can anyone please advise?
edit: I have edited my question and changed from POST to PUT because I am dealing with modification and not creation.
Having an "edit" as part of the URL smells of RPC-over-HTTP style programming. And tunneling edits through POST is also considered an REST anti-pattern.
REST is about putting the verbs in the HTTP method and using hypertext. Stefan Tilkov had an old but helpful introduction to REST that addresses your question.
Short: Wikipedia: REST - RESTful web APIs (especially the usage of POST: Don't use it for edits on none-collections - use it for creation)!
Please note that the purpose of restful url is to create a simple looking url and also consistent pattern making it easy for developers to learn how to use your APIs.
if you are hiding insensitive or trivial information there is no harm in using hidden tag.
A piece of Advice is either use /advertisement/childminder/123456/edit or use hidden style,but don't mix both styles in one application.
Use hidden fields to pass along information to the forms that is generated by the program, script, or web page, or that the form user might not know, such as the exact time the form was loaded.
Remember that hidden fields are not hidden from view. Your readers can see them if they view the source of your web page. So you should never use a hidden input field to store passwords or any other sensitive information.
I need to allow users to submit a form value containing html in their text inputs. This is an internally-facing application so it's reasonably safe to do so. I have succesfully used the
[ValidateInput(false)]
attribute on the method in question, but this inhibits all model validation for the method/view model in question, but I only want to allow html in one of the TextBoxes and do not necessarily wish to write my own guard clauses for every other piece of model validation in the same method/view model, when I could would prefer to continue using Data Annotations for all of the other properties in the view model.
It's too bad I cannot apply the [ValidateInput(false)] to only a single property of my viewmodel. I would assume that I need to override mvc's default model validation, but I cannot find any documentation on how to do so. Every search yields results describing only how to write my own custom validation attributes, which isn't correct for the problem I'm trying to solve.
Thanks!
You would have to upgrade your aplication to ASP.NET MVC 3. There you have AllowHtmlAttribute, which you can use to disable input validation on property level. ASP.NET MVC 3 is backward compactible with ASP.NET MVC 2 so the upgrade should be easy.
I am working on a new web project based on Spring MVC 3. Now trying to decide to use spring form tags or not. Personally I don't like to use any tags other than HTML and JSP. It takes time to learn them and it is so hard to understand how they are rendered and the error msgs when they occur. So are there any outstanding advantages to use them? Thank you!
The Spring MVC form tags are very basic indeed, but they're better than nothing. If you're trying to render HTML forms, with submissions, error messages, and resubmissions, they take a lot of the annoyance away (especially for <select> fields, which are a huge pain to handle otherwise).
For anything more complex, they're pretty useless, but for forms, I see no reason to not use them.
Another benefit of spring tags is that when you make a mistake and you write the name of a property which doesn't exist in the object to populate it gives you an error, so you can easily find-out that you have to correct the name of the property in the path attribute of the tag.
The benefit of using the spring form tags is that you will get consistent data binding and error handling across your entire website. I would recommend wrapping the spring form tags in your own tags - this will allow you to easily swap in your own implementations at a later date if you find the spring tags lacking functionality you need.