Anyone notice that a client update with a bad ID skips allow/deny and returns no error!?

core
1

I was testing my allow/deny code for a Collection and I was trying to do a Collection.update from the client. Whenever I pass a random word as the id or a bad id (e.g. one from the wrong Collection) the Collection.update returns with no error and the allow/deny blocks never get called. The update of course fails, but there’s never an error thrown.

Without error returning, I can never display a specific error message to the user. Can someone confirm this is intended behavior - like a Meteor core level check if you’re passing in an id that doesn’t match any object in the Collection it gets rejected before any allow/deny calls? I am noticing result returns as 0 updated so I guess I can use that to return a generic error. But it seems like doing a check in my allow/deny would let me return a specific error to the user (e.g. Couldn’t find object matching that ID).

I also tested this in the Local Market app and the same thing happens.

2

In mongo, it’s not an error to call an update with a selector that doesn’t match any documents. An _id is just a special case of that.

For example, if you do Items.update({owner: "sashko"}, {$set: {x: "y"}}), it won’t throw an error just because I don’t own any items.

I think in this case the correct thing to do is to detect that no items were updated via the return value of update.

3 Likes
3

I see. So allow/deny is more about if the query is valid and there’s a selector match - then check if the allow/deny are valid, then perform the query.

Cool. I’m new here. Thanks for the response.

4

It’s not technically a question of the query being valid or not. A query with that selector is perfectly valid, it just doesn’t result in any updates, so there are no modified documents on which to call allow or deny rules.

However, if an invalid query is passed that will result in an error from the db.

1 Like