Sanitization and Dirty changes to update


#1

I am about to experiment my real-life Meteor framework from some packages.
(a how-can-we-do-it question, as well a nice-to-have-in-core)

I really think, being clear on these elements has a big part in the way we structure our app, select packages and have a good security strategy.

  1. Using some schema package for centralizing validation,
    and maybe an autoform package so it creates a form without hard coding templates, but in other cases, still allowing hard coding templates,
    what would be the best place to put systematic sanitization (against XSS, injection, etc.), so I do not need to hard code it many times?
    1.1) Can Regex() clean malicious code? (I think, if we want to be bullet proof, better use server side methods(), rather than Allow/Deny) (especially for data entry/edit rather than data search)

  2. Dirty insert or change (values edited with different values than original but these inserts or changes not posted yet)
    In the context of using a server side method for updating a mongo document:
    If I have a form (likely a conditional template where the focused item is displayed as an input for editing)
    and I edit one or more fields, one after the other one, I have 3 choices:

A) Do I need to send all fields in a server method (from a Save button), update at once all fields in the document?

B) At each field change, call the update method (with attribute name and value), so we do not wait for all modifications for saving one field (in this choice, each field insert or edit would cause Meteor and/or Mongo to save a new version of the document that would grow in length that would be put somewhere else in the DB because needs more room than the previous save) : (

C) Or the stack (Meteor-Node-Mongo is taking care of detecting what is dirty and what fields did not change, and takes care of the best strategy? (we can imagine that sending over the wire just the new field datas could reduce transit amounth, but would increase work on the DB)

What is really happening and what is likely the best strategy? (according to behind the scene mechanisms already in place, and the way the stack works, beside the fact that we may wish to have latency compensation in some contexts)

  1. In that context, if I want to UNDO a change, using Oplog, is there a way it could undo the previous changes on a specific ID document (in the same insert/change batch identified a way or another as being from the same batch)?

And a way to read the previous values and flag those that changed?
So we can revert to those values on attribute basis or as a whole?


#2

Hey, I think people will have some trouble responding to this post because it is very long and has a lot of ideas at once. Maybe submit it as separate topics?


#3

I understand but I felt it is all related with what is basic core needed in secure CRUD.
The idea is to catch the “Best practice” way of Meteor for that.
(Secure and not counter-productive with the Meteor-Mongo way.)

if some people could add some insights or se something to address in core dev.

Thanks for your comment,
Marc