Meteor’s security system allows us to control database modification without having to define Methods every time we want to make changes.

We didn’t really need to create new Methods for updating and deleting data in database. We just needed to check if the user had permission to do these actions, and this was made easy by allow and deny callbacks. Using these callbacks lets us be more declarative about database modifications, and say what kind of updates can be used.

Multiple callbacks

We can define as many allow callbacks as required. We just need at least one of them to return true for the given change that is happening. So when (database).insert is called in a browser (no matter if it’s from our app’s client-side code or from the console), the server will in turn call whatever allowed- insert checks it can until it finds one that returns true. If it does not find any, it will not allow the insert, and will return a 403 error to the client.

Similarly, we can define one or more deny callbacks. If any of those callbacks return true, the change will be cancelled and a 403 will be returned. The logic of this means that for a successful insert, one or more allow insert callback as well as every deny insert callback will be executed.

In other words, Meteor moves down the callback list starting first with deny , then with allow , and executes every callback until one of them returns true .