Take the 2-minute tour ×

I am using Meteor 4.2 (Windows) and I am always getting the "update failed: 403 -- Access denied. Can't replace document in restricted collection" when I am trying to update an object in my collection. Strangely I had no problem inserting new ones, only updates are failing.

I tried to "allow" everything on my collection:

    insert: function () { return true; },
    update: function () { return true; },
    remove: function () { return true; },
    fetch: function () { return true; }

But still, this update fails:

    _id: Session.get('current_map') 
}, {
    name: $('#newMapName').val()

Is there something else I can check? Or maybe my code is wrong? Last time I played with my project was with a previous version of Meteor (< 4.0).

Thanks for your help.

PS: Just for information, when I do this update, the local collection is updated, I can see the changes in the UI. Then very quickly it is reverted along with the error message, as the changes has been rejected by the server-side.

share|improve this question
add comment

2 Answers

up vote 6 down vote accepted

Alright, the syntax was actually incorrect. I don't understand really why as it was working well before, but anyway, here is the code that works fine:

}, {
    $set: { 
share|improve this answer
It's the $set bit (the content to save must be wrapped in $set), I just ran into this problem and thanks to your answer I spotted my accident, thanks :) –  Bob Davies Dec 18 '12 at 12:07
Thanks, you saved my day :D –  Nick Mar 3 '13 at 16:34
add comment

It seems like it must be related to what you're storing in the 'current_map' session variable. If it's a db object, then it probably looks like {_id:<mongo id here>} which would make the update finder work properly.

I ran into the same issues, and found the following to work

Blocks.update {_id:block_id}, {$set: params}

where params is a hash of all the bits i'd like to update and block_id is the mongo object id of the Block i'm trying to update.

Your note about the client side update (which flashes the update and then reverts) is expected behavior. If you check out their docs under the Data and Security section:

Meteor has a cute trick, though. When a client issues a write to the server, it also updates its local cache immediately, without waiting for the server's response. This means the screen will redraw right away. If the server accepted the update — what ought to happen most of the time in a properly behaving client — then the client got a jump on the change and didn't have to wait for the round trip to update its own screen. If the server rejects the change, Meteor patches up the client's cache with the server's result.

share|improve this answer
add comment

Your Answer


