Q:

Form Validation and Security with Meteor Methods

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?

A:

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

