When I started this Meteor project, I was following best practices:
client
Meteor.call('changeAvatar', id, (error, response)=> {
server
changeAvatar: function (user, fileId) { Meteor.users.update(...
But then I found myself writing this:
React client only, no server:
saveDetails (e) { e.preventDefault(); Meteor.users.update({....
I know it’s wrong, but can someone provide reasons as to not do this? thanks
Updating the DB on the client requires that you either have the Insecure package installed (obviously a bad idea) or that you have configured allow rules for your collections, which is generally considered a bad way to handle security in a complex application, although it can work for a small one.
Leaving the ability for a user to update your DB from the client opens up a world of security issues. If you let the users insert directly into your DB from the client, what is to me from going to your app and writing whatever I want to your DB?
If you are writing code for an app that strangers actually use you just can’t trust the client. You should validate every input from it on the server.
Client side db operations can be secured in very simple ways. I realize the “don’t use client side operations” line is the mantra of the day, but it’s only because a large majority doesn’t realize how simple it is to secure your client side code.
I’m with you. Just publish what the client can access, and only allow what the client can modify. I’ve yet to be bitten by the scalability or security monsters. I think the aberration to mini-mongo comes from the “What if I become the next Facebook!” kind of mentality.
There does exist a large chance of opening up a large number of security holes if trying to use allow/deny with complicated logic to apply write security to your collections. This is what many people had been doing for much of the early years of meteor. Why? I’m really not sure. Maybe they didn’t know other options existed or they were resistant to change like so many people are. This lead to the “don’t use allow/deny, use validated methods” mantra that exists today. The issue is that the same risk of security holes in complex method logic exists if you don’t know how to properly secure your methods. Using Simple-Schema with Collection2 essentially creates validated methods that are super simple to reason about, and which allow client side database operations. Then you just need some very basic allow checks for minor things that Simple-Schema doesn’t handle.
Unfortunately this idea that you shouldn’t use allow/deny will probably never go away. Partly because it’s currently codified in meteor best practices, and partly because every time someone brings up allow/deny there has to be that guy that stands up and screams DON’T USE THAT, IT’S NOT SAFE!
I agree that you can probably get by with just having good schemas on your collections, and allowing updates from the client on specified collections. But this isn’t “securing your client side code” as you said. With those schemas you are securing your server. It’s server validation of client inputs, and it goes in line with that big rule in web application development: “Don’t trust the client.”
However you get there is fine. For me it is both not allowing the client to write the db, and having schemas on my collections.
The whole point of using schemas and allow/deny is not trusting the client. It makes client side operations possible by securing your database from unauthorized write access. I agree that people should do what works for them and if that’s using schemas and methods then great. All I’m saying is that anyone who says that you can’t make client side operations secure in a relatively simple manor is misinformed.
I actually took that challenge and am listed in the results there 
Oh that’s right, I didn’t even notice! Good job on getting it right 