I found that I was confused while reading through this part of the book.
I did some deeper digging to clarify my confusion.
It was at first glance difficult for me to understand why Meteor Methods were being declared in a file that was accessible to both the client and the server in the /lib/collections directory. This seemed like a poor security choice at first. I found this excellent explanation on the blog:
There's no security risk, since all the client can do is execute the code you specify in the method, and even if that code was somehow tampered with, the part of the method that runs on the client will only affect the in-client copy of the database (and any discrepancies that may arise will get automatically corrected by Meteor from the "real", server-side db).
My suggestion is that this be put into the actual book - I think this is something everyone else who reads the book would want to know also... But then again, I guess we all think everyone is like us right?
Much like in Chapter 8 you mention:
"To fix this, we'll set up some permission rules. First, create a new permissions.js file inside lib. This makes sure our permissions logic loads first (and is available in both environments):"
SachaG
commented
8 years ago
I found that I was confused while reading through this part of the book.
I did some deeper digging to clarify my confusion.
It was at first glance difficult for me to understand why Meteor Methods were being declared in a file that was accessible to both the client and the server in the /lib/collections directory. This seemed like a poor security choice at first. I found this excellent explanation on the blog:
My suggestion is that this be put into the actual book - I think this is something everyone else who reads the book would want to know also... But then again, I guess we all think everyone is like us right?
Much like in Chapter 8 you mention: