Hey all,
quick question that I’ve been going over in my mind for a bit, but wanted to get some other opinions.
Let’s say we have a collection, Settings, and that all of our allow/deny rules are set up to prevent client-side manipulation of the collection. Also, we don’t have any server-side methods that provide access to the collection.
Are there other touch points within the app that could/should be locked down or looked at? The theory is that the collection provides the reactivity and cursor functions of a collection, but that it is read-only, meaning that really the only way to edit the values in the collection is through a mongo interface.
Just something I’ve been mulling over and wanted to hear some other opinions from those with a more in-depth understanding of how meteor works…
If by settings, you mean something like application-level settings, learn about the settings.json file.
Otherwise, I would go with client-side collections if the fields and values do not change much.
If they do change frequently, as long as you remove insecure and autopublish, you are safe. Clients won’t be able to change them on the server side anyway.
Hm, perhaps a bad choice of collection names.
Not so much app-level settings, more like a set of data that needs to be read-only but still be able to be queried and pub/subbed like a normal collection.
I guess my real question is: are server-side methods the only way to manipulate data in a collection if allow/deny rules are set up correctly. More of a security question that I’ve been thinking about after watching that one crater conf vid.