Understanding "Not permitted. Untrusted code may only update documents by ID." Meteor error

In Meteor 0.5.8 the following change was introduced:

Calls to the update and remove collection functions in untrusted code may no longer use arbitrary selectors. You must specify a single document ID when invoking these functions from the client (other than in a method stub).

So now if you want to push arbitrary updates to the db from the client console, you have to do something like:

People.update({_id:People.findOne({name:'Bob'})['_id']}, {$set:{lastName:'Johns'}});

Instead of:

People.update({name:'Bob'}, {$set:{lastName:'Johns'}});

I thought that this security issue controlled by setting the Meteor.Collection.allow and .deny functions in conjunction with the autopublish and insecure packages. I liked being able to interact with the db from the Chrome JavaScript Console.

What is the motivation for the changes in Meteor 0.5.8?

Solution 1:

From the Meteor blog:

Changes to allow/deny rules

Starting in 0.5.8, client-only code such as event handlers may only update or remove a single document at a time, specified by _id. Method code can still use arbitrary Mongo selectors to manipulate any number of documents at once. To run complex updates from an event handler, just define a method with Meteor.methods and call it from the event handler.

This change significantly simplifies the allow/deny API, encourages better application structure, avoids a potential DoS attack in which an attacker could force the server to do a lot of work to determine if an operation is authorized, and fixes the security issue reported by @jan-glx.

To update your code, change your allow and deny handlers to take a single document rather than an array of documents. This should significantly simplify your code. Also check to see if you have any update or remove calls in your event handlers that use Mongo selectors (this is quite rare), and if so, move them into methods. For details, see the update and remove docs.

So basically, from my point of view, you almost never want the behavior to be able to update and delete arbitrary sets of documents from the client without any more specific knowledge (like the id of the document).

When prototyping—which I'm guessing is what you're doing—I suppose it can get in the way, but then if you ever want to get your code into production, I believe the pros outweigh the cons. This also comes down to the security declarations (allow and deny) being easier to specify after this change.

Hope that gave you some more information.