Pretty much what is written in the title.
I want to do client side validation of forms in rails, so that whenever a user does not enter some "required" fields, it throws errors and do not submit the form at all (as opposed to doing that on the server side and redirect_to :back).
Any examples on how to do that?
Take a look
http://railscasts.com/episodes/263-client-side-validations
Showing validation errors inline as the user is filling out the form can lead to a better use experience. Learn how to do this using the Client Side Validations gem.
Related
I'm trying to a CSRF protection to an existing MVC4 web application which uses DevExpress grids. I've added the Html.AntiForgeryToken() into the forms on the aspx pages (which contain ascx as partials containing the grids) and can see the __RequestVerificationToken and it's value clearly in developer tools when a save is called.
I've tried commenting out all my ValidateAntiForgeryToken attributes bar one - I went with the delete post method for simplicity (And also to eliminate the DevExpress grids messing with it) and I still keep coming up against this error:
There was a HttpAntiForgeryException
Url: http://localhost:54653/Users/Delete/f86ad393-0039-44e8-beed-a66dbab9266e?ReturnURL=http%3A%2F%2Flocalhost%3A54653%2FUsers
The exception message is
The required anti-forgery form field "__RequestVerificationToken" is not present.
Does anyone have any idea why this might be happening? Could it be that the error is non-descriptive and it's actually that the token doesn't match rather than that it doesn't exist? In previous answers to this question people just say "oh, you have to add the token," which is obviously not helpful here.
Are you submitting the form manually through Ajax? If that's the case, you need to pass the anti forgery token as another parameter with the name "__RequestVerificationToken".
Point 1 : Make sure if your application is has https secure protocol. Please load in https.
Point 2 : In case of DevExpress you have to call in the below pattern.
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
After struggling with this for days I had a thought - maybe the browser is stopping the cookie being written. I did a search for dev servers and cookies not being written, and found that with Chrome and IE10 and up that there's problems writing the cookies.
I downloaded Firefox and tried it with that and it worked instantly. I then reapplied all the validate attributes to the all the controller methods and the all worked, every single one of them! Even the DexExpress postbacks seem to be working correctly.
I'll carry out more exhaustive testing, but for now, I think we're there.
Not exactly. If MVC AntiForgeryToken is already defined on page where you are using MvcxGridView and you want to protect grid actions you should send this token back to server during grid client side begin callback event.
settings.ClientSideEvents.BeginCallback = "function(s,e) { e.customArgs[\"__RequestVerificationToken\"] = $('input[name=\"__RequestVerificationToken\"]', $(s.GetMainElement())).val(); }";
Thank you for answering my previous questions and I appreciate the effort put in by you in developing Moqui.
In the field tag there is an attribute of validate-parameter so could please elaborate the use of it and how to use that attribute. Thanks in advance :-)
To be specific, it sounds like you are looking at the XML Form field element (form-list.field, form-single.field).
A form field can be validated based on the validation settings in a service parameter (there are many validation options there) or an entity field (just a couple validation options there). This is done automatically when a form submits to a transition that has a single service-call element (i.e. not an actions element), and these attributes are populated automatically. You can also specify manually which service/parameter or entity/field to use for validation.
This is all part of the support in the framework to do client side validation with JavaScript using server-side validation settings. Note that the validations are also done on the server, but you don't have to define/implement them twice.
I need to validate user email input from the site. Of course there is django.core.validation. However is not it easier to just use jquery validation plugin without sending POST data before all fields are valid? Or it is just better to validate threw views? Why?
This is a design decision that you can choose to make. If you need the real-time validation of your fields, then jquery-validation is the way to go.
However, if you want the validation to be done on a postback, you'll be better off using Django's form validation to get the job done.
If you do decide to do the validation on the postback, all of you have to do is use the EmailField and django will take care of the rest.
I'm having a bit of a trouble understanding how to fit a particular design flow I have into a proper REST architecture. Let me explain the flow:
I'm creating technical support website where users can submit ProblemRequests. On the front page, the user selects all the categories he's having trouble with and clicks "get help," which then redirects him to the next page where he fills out some forms to submit his request. Here are the pages:
Page 1 - Select Problem Categories
Page 2 - Fill out Problem Request
Page 2 basically acts like the NEW action for a ProblemRequest. The thing is each ProblemRequest depends on multiple ProblemCategories, so a nested route isn't going to work here. The next thing that comes to mind is sending in all relevant ProblemCategories ids as an GET param for the NEW ProblemRequest action, but I would rather not expose the IDs in the URL.
A Multi-Part form sort of comes to mind, but that involves making ProblemRequests have state, where some would be complete and others incomplete. I don't want to deal with the implications, because in reality this is a one page submission, not a very long-winded process.
What would work ideally is to override the NEW action for the ProblemRequests controller to respond to POST operations, but I don't know if this is considered bad programming practice. Is this a cardinal sin? Is it okay for me to change the NEW action to respond to POST instead of GET?
Please advise,
Thanks in advance.
Keep it simple. Is there any reason for the round-trip to the server? I'd just make the two "pages" a single page and maintain the state of the selected categories client-side.
Use a multi-step form: http://railscasts.com/episodes/217-multistep-forms
You can save the IDs in the session, and the model won't get saved in the DB until you are finished filling out the info. Works great for simple 2 or 3 step forms.
For more complex wizards you could use a gem like https://github.com/schneems/wicked
I'm writing an "Account" module which should take care of everything about accounts: registration, login/logout, user administration, password recovery, account activation, etc.
So I thought it would be best to reuse whatever the module's DefaultController::actionRegister() generates to show on the main page.
So my question is: how to create a new "sub request" (similar to CController::forward()) from any controller (either SiteController, read: from views/layouts/main.php, or another controller, eventually of another submodule) to a given module/controller/action?
I've tried with $this->forward() from within my application layout without success: it shows a blank page, no error whatsoever.
Thanks
You are trying to make a widget. Avoiding tightly coupled classes and actions will make your application more secure, easier to maintain and improve and far more reusable.
"Inline partial redirects" are never the answers to any question, at least in Yii.