Confused about Collection permissions

help
1

I’m still relatively new to Meteor so please forgive me if this is a stupid question.

I was under the assumption that all Methods are controlled by the server, meaning that the client can’t alter them right?

For example :

if (Meteor.isServer) {
  Meteor.methods({
    'delete.stuff': function() {
      MyCollection.remove({uid: Meteor.userId()});
    }
  });
}

If that is the case what is the need for the following? :

const MyCollection = new Mongo.Collection('myCollection');

MyCollection.allow({
  insert: () => false,
  update: () => false,
  remove: () => false,
});

MyCollection.deny({
  insert: () => true,
  update: () => true,
  remove: () => true,
});
2

Answered my own question again…

Please correct me if I’m wrong.

Methods are indeed protected, but that doesn’t stop any client from running any other calls to your collection in the browser console if it’s not locked down with allow and deny rules.

That said, is it important where the allow / deny rules are set?

3

Methods can also run in the client when implementing optimistic UI i.e. updating the UI while executing the same code in the server. Methods will run in the client if you include the code in the client and do not include it within the Meteor.isServer check.

Collections can also be manipulated in the client. Place the allow/deny rules in the collection file i.e. where you create the new collection.

1 Like
4

So the allow and deny methods are ignored by the server then? They are only enforced for the client? Is that correct?

5

Yes. Allow/ Deny rules are specified on server side code only, but only apply to insert/update/remove when done on the client (server side code is permitted to do anything).
Allow / Deny rules do not apply to Methods at all.

2 Likes
6

Just so there isn’t any confusion. The default behavior of a collection is to not allow client side operations. You have to explicitly write an allow rule to allow client side ops.

There is one exception to this rule and that is the users collection allows the profile key to be modified by default. I find it best to write a deny rule to close this security hole and use a separate collection for user profiles

2 Likes
7

Thanks for this tip. Luckily I am already doing this anyway as I didn’t like the fact that user profile meta is stored in the users collection, seemed very risky to me, so I set up a separate collection just to handle that stuff.