Meteor allows and rejects

Allow and deny

Meteor's security system does not require us to manually check the data in our respective functions each time we modify it.

For example, for a blog system, we often need to do a lot of things, add properties to new posts, and make specific checks when posting. These actions are all done around the post object, so we should set up a special function for the post for security checking.

But on the other hand, we don't want to write specific functions for the simple things of modifying a post or deleting a post. W e just need to check if the user has permissions before we do this. At this point we need to use the allow and deny callback functions.

These callback functions make it easy for us to define which data can be modified and which can be deleted. In addition, these callback functions integrate the user system to determine permissions.

Multiple callback functions

We can define as many allow allow as needed. B ut we only need one of them, at least one of true to get the operation to pass validation. W hen Post.insert (whether in our app's client code or in the browser console), the server runs the allow callback function set for insert one by one until one of them true If such an allow callback function does not exist, the server does not allow insert operations and returns a 403 client.

Similarly, we can define one or more deny deny functions. I f one of the callback functions true the operation is canceled and 403 This means that a successful insert operation requires at least one allow allow true and that all deny functions return false

"Note: n allow_deny/e indicates that the function has not been executed"

More intuitively, Meteor starts by rejecting the callback function, allow executing one by one until one true

A practical example of this pattern is the establishment of two allow() one to check whether the post belongs to the current user and the other to check whether the current user is an administrator. If the current user is an administrator, because at least one callback function true make sure they can update any posts.

Delay compensation

Remember when we said earlier that variable functions of a .update() use a delay compensation technique. S o when you try to delete a post from your browser's console that doesn't belong to you, you'll see the post disappear for a short time and reappear immediately. This is because the post was not actually deleted from the background, and the deletion was rejected in the background.

This behavior is not a problem on the console (developers are free to use the data for development). H owever, you need to make sure that this behavior does not occur on the user interface. For example, you need to make sure that users don't see delete keys for posts that they can't delete.

Fortunately, you can use the same code for rights management on the client and service side (for example, you can write a canDeletePost(user, post) put /lib which usually doesn't require much extra code.

Service-side permissions

Only database operations from the client need to be verified by the permission system. All operations on the service side are considered secure and do not need to be verified by the permission system.

This means that if you create a deletePost and the function can be executed by the client, any user can delete any post. Therefore, you may not want to do that unless you also verify user rights in the function.