Meteor audit argument checks vs Simple Schema package / Collection2

help
1

Until now I have just been using meteor audit argument checks package and doing my own server side validation I’m now looking at the collection2 package and simple schema package.

I really like the collection2 package but don’t believe in having the client create a collection but just have the client call a meteor method and the server create the db collection. Also related to “Meteor Methods vs Client-Side Operations”

I know you can you call the collection2 insert method on the server (not sure there is a point this if you’re already doing it via meteor method call) but then you can’t add anything custom for example if I want to add a createdDate or add the userId. (I might be missing something here I know you can do function calls inside the schema)

So I was just looking at using simple schema package just for the server side validation however isn’t this the same as just having the audit argument checks package?

1 Like
2

There are some key differences and bullet points I can add to your comments:

  • A simple schema can be used in a check statement as a match pattern
  • audit argument checks only makes sure (at runtime) that you’ve checked the types/patterns of all arguments you pass to methods, publish functions etc. Also, check(!) out https://github.com/East5th/check-checker for a companion to that
  • collection2 adds some useful decorators to simple schema (like enhanced this in autovalue etc)
  • collection2 allows for validating the complete insert/update call in a single go. and it is reactive. provides you with a very good context to your validation status.
  • with collection2, you can also bypass validations if you want
  • using collection2 does not go against using method. In your client side code you call your server method which calls collection.insert/update which goes through collection2 and you can report back its errors.
  • you can still use your methods on both the client and the server and make use of latency compensation as well as collection2’s reactive validation context
  • you can use collection.insert directly for some simple use cases as well. the validation/security is pretty solid. (I like methods, too. But why always use a hammer, right?)

Also, you might want to check out https://github.com/jagi/meteor-astronomy with which the author is working on the nested branch rigorously on a new version. It is a fresh take on ORM and is certainly worth some attention.

I’m currently using the aldeed packages to full satisfction while keeping an eye on astronomy.

2 Likes
3

@serkandurusoy thanks this is great, how are you using collection2 are you inserting a doc via the client or meteor method?

Also

using collection2 does not go against using method. In your client side code you call your server method which calls collection.insert/update which goes through collection2 and you can report back its errors.

Is’nt this a bit of overhead for nothing IE you call a method method which has the checks and then it runs the collection2 checks not better to just use simple schema

Right now I have audit checks with simple schema, I call a meteor method from the client run audit checks and then the simple schema check and insert doc is there any value to add collection2? It feels like I would be doing the simple schema check twice

4

how are you using collection2 are you inserting a doc via the client or meteor method

It depends.

First of all, I make sure I am very thorough with the schema definition. Especially with very extensive custom validations with cross check other fields as well as the current user’s role and rights.

Then, if the collection does not have complex rules about the conditions which allow/deny its insert/update, I write my access rules using ongoworks:security and do normal insert/update. Ongoworks:security helps here because it allows creation of reusable constraint filters and it is all based on deny, which is much safer than allow.

Also, if I’m using autoform, I’m usually more inclined towards using insert/update rather than methods.

But, if the collection has rather complex modifier rules, or rules that can only be run on the server, I then set up a method.

Finally, if I need to partially update a document, where a full form that represents the complete schema is not what I want, I proceed with a method.

Is’nt this a bit of overhead for nothing

Collection2 is very valuable here not only because it provides automatic schema validation, but it also provides a very extensive this context within autoValue and custom which allow me to implement business rules within the schema along with the schema rules. So it definitely pays of.

Some may argue that business rules and schema rules are two different contexts and should be separated.

Well, I do agree but have a different take. As you might perhaps already have gathered from my explanation above:

  1. I set up business rules outside the schema
  2. I set up the complete schema with schema (type) rules, but also incorporate the business rules into autovalue and custom blocks
  3. I then reuse those business rules elsewhere, like ongoworks:security chains and method bodies.
5

My 2c:

I started with simple-schema/autoform/collection2 and allow/deny as it seemed like the “standard” approach. But, over time, I felt this was not the right way:

  1. I stopped using allow/deny altogether and used methods instead. With a single pattern, my code is easier to maintain (as @serkandurusoy allow/deny is limited anyway, and, IMO, dangerous).
  2. I stopped using business rules in schema, for the reason @serkandurusoy explained above.
  3. I stopped using autoform, as I think the package is overly complex and does not take the right approach to forms.

My current status is that I now use only the most basic features of simple-schema/collection2, mainly as an extension to the “check” package for database insert/update. I am still waiting for an even more lightweight way. I tried astronomy, but it also is too heavy.

1 Like
6

@Steve you should definitely give ongoworks:security a try. It introduces a very fresh take on defining and reusing collection security rules.

7

Some of my methods require non-trivial logic when granting permission and updating data. I am talking about performing joins, accessing server-only or client-only data, insuring coherence among multiple collections, fine tuning latency compensation (meaning permissions are not checked the same way on client and server), etc. IMO, implementing this with allow/deny, even with the help of ongoworks:security, leads to code difficult to maintain.

8

As long as you keep fine grained security methods and functions and compose them either by wrapper methods and/or with context aware blocks such as allow/deny, ongoworks:security, methods, publish functions, UI helpers, you can create a very solid security model for your app. I believe dismissing a piece of technology by saying it is wrong is itself inherently wrong. Everything has its place IMHO.

9

Ok, I replaced “wrong” by “leads to code difficult to maintain” :- )

1 Like
10

Are you still checking your documents with check and using Simple Schema? I’ve run into a problem where I can’t use the schema in check anymore and I need check because I’m using the audit-argument-checks package. Just wondering how you are doing your checks

11

I’m still using Simple Schema but I’m not sure about anymore. The package feels like it’s getting outdated and it might be best to avoid using it.