I don't want just all of my users being able to insert/destroy data.
4 Answers
While there is no documented way to do this yet, here's some code that should do what you want:
Foo = new Meteor.Collection("foo");
...
if (Meteor.is_server) {
Meteor.startup(function () {
Meteor.default_server.method_handlers['/foo/insert'] = function () {};
Meteor.default_server.method_handlers['/foo/update'] = function () {};
Meteor.default_server.method_handlers['/foo/remove'] = function () {};
});
}
This will disable the default insert/update/remove methods. Clients can try to insert into the database, but the server will do nothing, and the client will notice and remove the locally created item when the server responds.
insert/update/remove will still work on the server. You'll need to make methods with Meteor.methods that run on the server to accomplish any database writes.
All of this will change when the authentication branch lands. Once that happens, you'll be able to provide validators to inspect and authorize database writes on the server. Here's a little more detail: http://news.ycombinator.com/item?id=3825063

- 2,489
- 1
- 19
- 15
-
-
Is it also possible to secure a Collection from being read from the client? – HansPinckaers May 03 '12 at 12:29
-
1
-
This technique isn't necessary in Meteor 0.5.0 and above. Use `allow` and `deny`. – debergalis Dec 14 '12 at 01:34
[UPDATE] There is now an official and documented Auth Package which provides different solutions to secure a collection.
On a CRUD level :
[Server] collection.allow(options) and collection.deny(options). Restricts default write methods on this collection. Once either of these are called on a collection, all write methods on that collection are restricted regardless of the insecure package.
And there is also insecure
to remove full write access from the client.
source : Getting Started with Auth (thanks to @dan-dascalescu)
[OLD ANSWER]
Apparently there are working on Auth Package(?) that should avoid any users taking full control on the db as it is now. There is also someone suggesting that there is an existing solution (workaround) by defining your own mutations (methods) and make them failed if they attempts to perform an unauthorized action. I didn't get it much better but I think this will often be necessary since I doubt the Auth Package will let you implement the usual auth logic on a row level but probably only on the CRUD methods. Will have to see what the devs have to say.
[EDIT] Found something that seems to confirm my thoughts :
Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality.
Sources of this answer :
Accessing to DB at client side as in server side with meteor
-
-
Also se this thread on Quora with an answer from one of the Meteor developers: http://www.quora.com/Meteor-web-framework/Whats-cool-about-Meteor/answer/Rory-I-Sinclair/comment/878076 – dentarg Jun 17 '12 at 18:24
-
1@nrako: might you update the answer to mention https://github.com/meteor/meteor/wiki/Getting-Started-with-Auth ? – Dan Dascalescu Oct 10 '12 at 07:59
A more succinct way:
_.each(['collection1', 'collection2'], function(collection){
_.each(['insert','update', 'remove'], function(method){
Meteor.default_server.method_handlers['/' + collection + '/' + method] = function(){}
});
});
or to make it more idiomatic:
extend meteor:
_.extend(Meteor.Collection.prototype, {
remove_client_access: function(methods){
var self = this;
if(!methods) methods = ['insert','update','remove'];
if(typeof methods === 'String') methods = [methods];
_.each(methods, function(method){
Meteor.default_server.method_handlers[self._prefix + method] = function(){}
});
}
});
Calls are simpler:
List.remove_client_access() // restrict all
List.remove_client_access('remove') //restrict one
List.remove_client_access(['remove','update']) //restrict more than one

- 11,945
- 6
- 37
- 52
-
Just wanted to mention that this is no longer necessary, since v0.5.0 introduced authentication. See http://docs.meteor.com/#accounts_api. @greg: any chance you could update your answer? – Dan Dascalescu Nov 08 '12 at 06:49
I am new to Meteor, but what I have come across so far are these two points
You can limit what a client can access in the database by adding parameters to the
find
command in the server-sidepublish
command. Then when the client callsCollection.find({})
, the results that are returned correspond to what on the server side would be, for example,Collection.find({user: this.userId})
(see also Publish certain information for Meteor.users and more information for Meteor.user and http://docs.meteor.com/#meteor_publish)One thing that is built in (I have meteor 0.5.9) is that the client can only
update
items by id, not using selectors. An error is logged to console on the client if there is an attempt that doesn't comply.403: "Not permitted. Untrusted code may only update documents by ID."
(see Understanding "Not permitted. Untrusted code may only update documents by ID." Meteor error).
In view of number 2, you need to use Meteor.methods
on the server side to make remote procedure calls available to the client with Meteor.call
.

- 1
- 1

- 579
- 4
- 9