Lets assume one uses a form to update a doc in a collection.
Generally, upon submit, one would use some type of form validation process to verify the sanity of the fields in the form. Then after the data verifies, lets assume that the data is passed to a meteor method to actually update the collection.
But theoretically, a user could use the javascript console to fabricate a meteor call to the same update method. For reasons of security, in order to validate submissions made via the console, doesn't this imply that the fields must be verified for sanity in methods too?
So, for normal submission cases via the form, this will cause the same fields to be verified twice (once during form validation, and once within the method).
Is there an elegant way to get around the redundant verification, or must all methods have a redundant field verification step?
You should consider using aldeed:collection2 for validating updates to collections. Normally you define your schema in /lib and then updates will be validated both on the client and on the server but you only have to write the code once. If you want to avoid double work then only validate on the server because you can't trust the client. This is not recommended because the cost of client-side validation is borne by your user, not your server. You can create a better UX if you validate the fields as they are entered instead of onSubmit because you will give the user feedback earlier.
My basic validation approach:
Event handler on each form field on change event change(){}. This does things like making the field border green for a valid entry, red X for an invalid one.
Collection2 validates document inserts/updates on client
Methods validate their arguments
Collection2 validates document inserts/updates on server
More reading:
http://0rocketscience.blogspot.com/2015/07/meteor-security-no-2-all-praise-aldeed.html
http://0rocketscience.blogspot.com/2015/12/meteor-security-no-4-extending-match.html
Related
I implement QuickFix client and I parse SecurityDefinition message ('d') with many user-defined fields. The service provider wants me not to validate user-defined fields, as he says that they add new fields from time to time and don't want to make us (clients) dependant of this.
Is there a way to cancel validation of user-defined fields for one specific message only?
Thanks...
Take a look at the Configuring QuickFIX page, in particular the ValidateUserDefinedFields parameter:
ValidateUserDefinedFields: If set to N, user defined fields will not be rejected if they are not defined in the data dictionary, or are present in messages they do not belong to.
This does not turn off validation of one particular message of course. It turns off validation for User Defined Fields in messages where they are not defined in the Data Dictionary. If the SecurityDefinition message is the only one they add fields to without prior notification then setting ValidateUserDefinedFields to N is probably good enough for you because:
In other messages, either you defined User Defined Fields in your Data Dictionary and they are validated, or you haven't and they are not validated. In the latter case because you probably won't use those fields there's no harm.
In SecurityDefinition only the User Defined Fields you put in your Data Dictionary are validated, other UDF's aren't which is what you want.
If there's still a use-case that would prohibit you from using that configuration option, please let me know in the comments section.
I have a very long order form that enables saving drafts. If saved as draft, only order name is required but when actually placing an order a more thorough validation is required. I implemented this by using different validation groups. When editing the order I display two buttons: "Save draft" and "Place order". Each of them performs validation using a different validation group.
But now I would like to make a button on the list of orders which enables to change order status from 'draft' to 'placed' directly. To do so, validation must be performed without displaying edit form and submitting it. I would just like to validate the entity that is already in the database. I can use the validator service and everything is simple as long as the data is valid. But in case data isn't valid, I would like to redirect user to the edit form with fields with missing data highlighted. The idea seems to load data from database into the form and run validation as if that data were sent using a browser but execution of this doesn't seem to be trivial because Symfony2 triggers validation on form only when binding the request.
I was going through the Symfony source code and found s class called Symfony\Component\Form\Extension\Validator\EventListener\ValidationListener. It seems to attach itself on the FormEvents::POST_SUBMIT event. Is there a way to trigger this event manually from the controller without request binding? Or are there any alternative approaches to my problem?
Just to point out the correct answer already given by Matjaž Drolc in the comments:
If you want to validate a form without getting the data from the request, you have to call the form->submit() function, because Symfony does not validate the fields if they are not marked as submitted, which is done by this function.
Call the function like this
$form->submit(array(), false);
With an empty array as the submitted data and not clearing the missing fields.
The title may not be as accurate, if someone finds a better one and can update it, please do so :)
I have a small CMS to edit users.
I'm using Zend Framework 2 + Doctrine 2.
I have a fieldset + form to add a user and (possibly) the same one to update them.
The User entity has the following fields:id, username, password, email.
The fieldset has two validators that check if the username and the email already exist.
Since I'm using the same to update the users, when I change for example the username of the user and keep the email the same, it throws an error that the "email exists" (which is normal due to the validator) and the same when I change the username and keep the email etc.
What I want is to avoid that behavior and make it so it checks them only when they are really changed/updated.
I thought of some ways, but I'm not sure what the "best" approach would be to this.
Hardcode the whole thing, by checking if the fields change and then do the validation (which makes the whole fieldset pretty much useless)
Make a function in the User entity that accepts an array with the new values, then compares them to the old ones and passes the changed ones to a "validation" function that returns the errors (which is mostly like the previous way, but I guess a bit more structured)
Write a validator and attach it to a new form which will query the db to check if the email/username exists and it's not already in use by the particular id, but I'm not quite sure on how to write it since I can't figure out how to pass the id and the field to the validator
I guess the 3rd one would be the best since it does 2 jobs at one time, by checking if the field changed and is not already in use by another user.
What do you suggest? How do you deal with that kind of scenario?
I can post any code that is needed, but I think this is more of a structural problem and that the code I used is too common and easy to figure out.
Is it possible in Codeigniter to run a multi-step Form validation, such that, when an error has been found, the form validation will stop (not validating the other Form validation rules)?
With the set_rules() and run() method of the Form_validation class, all the rules are checked even if it does not pass the first one.
Or is it better to validate those criteria in my model in the particular order (such that it stops on a validation error) and pass the single error message to my view?
Ralph, I am not sure you can do it with standard CI validation library.. You may need to extend/overwrite it in order to achieve what you want. You can display a first error message individually, but in the background the full data check would run.
Depending on how complex the data validation you need, you could also get some jQuery plugin to roughly check the data before the form is submitted. This will reduce the risk of bad data being sent and may reduce the overhead on server side.
I doing a multi page form, but I'm not using sub form - just persisting the data in mySQL.
I want to use validators on each form, but to allow the form to submit even if validation fails. I want to use the validators instead to post a flag in my database to say whether or not the form passed or failed validation.
The reason for this is to allow each form to be updated over a period of weeks, but the final submission of all the forms is then subject to whether each separate form validated (according the the flag set in the database).
Any tips would be apprecited, especially on modifying the validation script.
I don't think you need to modify anything.
Zend doesn't to JavaScript form validation, it is done server-side, so a form is submitted and POST/GET data is generated regardless. It is only in your action that you call $form->isValid($_POST);
The action you are submitting your preliminary and final steps should be different, such as processPreliminaryAction() and processFinalAction().
In your preliminary steps, you can iterate through submitted form Elements and call isValid() on each element, then you can save whether or not the field was valid in MySQL along with its value.
In your final submission, you call isValid() on the entire form and proceed with what you need to do only if it is TRUE.