允許與拒絕

Meteor 的安全系統(tǒng)不需要我們在每次修改數(shù)據(jù)的時候，在各自的函數(shù)里面進行手動檢查。

例如，對于一個博客系統(tǒng)，我們常常需要做很多操作，往新帖子上添加屬性，當發(fā)布帖子的時候進行特定檢查。這些操作都是圍繞帖子（post）這個對象進行的，所以我們應(yīng)該為帖子設(shè)置一個專門的函數(shù)進行安全檢查。

但在另一方面，我們又不希望為修改帖子或刪除帖子這些簡單的操作編寫特定的函數(shù)。我們只需要在這些操作之前，檢查用戶是否有權(quán)限就可以了。這時我們就需要用到允許（allow）和拒絕（deny）回調(diào)函數(shù)。

這些回調(diào)函數(shù)可以方便地讓我們定義哪些數(shù)據(jù)可以被修改，哪些可以被刪除。另外，這些回調(diào)函數(shù)還整合了用戶系統(tǒng)（account system），用以判斷權(quán)限。

多個回調(diào)函數(shù)

我們可以根據(jù)需要定義多個允許 allow 回調(diào)函數(shù)。但是我們只需要其中_至少有一個_返回 true 就可以讓操作通過驗證。當 Post.insert 被調(diào)用時（無論是在我們 app 的客戶端代碼調(diào)用，還是在瀏覽器控制臺調(diào)用），服務(wù)器會逐個運行為 insert 設(shè)置的允許（allow）回調(diào)函數(shù)，直到其中一個返回 true 為止。如果這樣的允許回調(diào)函數(shù)不存在，服務(wù)器就不會允許 insert 操作，并給客戶端返回一個 403 錯誤。

類似地，我們也可以定義一個或者多個拒絕 deny 回調(diào)函數(shù)。如果其中一個回調(diào)函數(shù)返回 true，操作就會被取消，并且返回 403。這意味著，一個成功的 insert 操作要求至少一個返回 true 的允許 allow 回調(diào)函數(shù)，并且_所有_拒絕 deny 回調(diào)函數(shù)都返回 false。

<%= diagram "allow_deny", "注：n/e 表示該函數(shù)沒有被執(zhí)行" %>

更直觀地說，Meteor 從拒絕回調(diào)函數(shù)開始，然后是 allow 函數(shù)，逐一執(zhí)行，直到有一個返回 true。

這個模式的一個實際例子就是，建立兩個 allow() 允許回調(diào)函數(shù)，一個用于檢查帖子是否屬于當前用戶，另外一個用于檢查當前用戶是否管理員。如果當前用戶是管理員，由于至少有一個回調(diào)函數(shù)返回 true，那就確保他們可以更新任何帖子。

延遲補償

還記得我們前面說過，數(shù)據(jù)庫的可變函數(shù)（例如 .update()）使用了一種延遲補償技術(shù)。所以，當你嘗試從瀏覽器的控制臺刪除一篇不屬于你的帖子的時候，你會看到帖子短時間內(nèi)消失，但馬上又會重新出現(xiàn)。這是因為帖子并沒有真正從后臺刪除，刪除操作被后臺拒絕了。

這樣的行為在控制臺上不是問題（開發(fā)者可以隨意支配數(shù)據(jù)進行開發(fā)）。但是，你需要確保這樣的行為不會出現(xiàn)在用戶界面上。比如說，你需要確保對于用戶不能刪除的帖子，用戶不會看到刪除鍵。

慶幸的是，你可以在客戶端和服務(wù)端使用一樣的代碼進行權(quán)限管理（例如，你可以寫一個 canDeletePost(user, post) 函數(shù)，把它放在一個共享的 /lib 文件夾下面），這樣做通常不需要太多額外的代碼。

服務(wù)端權(quán)限

只有來自客戶端的數(shù)據(jù)庫操作需要被權(quán)限系統(tǒng)驗證。服務(wù)端的_所有_操作都被認定為安全的，不需要被權(quán)限系統(tǒng)驗證。

這意味著如果你創(chuàng)建了一個服務(wù)端函數(shù) deletePost，而且這個函數(shù)可以被客戶端執(zhí)行，那么任何用戶都可以刪除任何帖子了。因此，你可能不想那么做，除非你在函數(shù)中也驗證用戶權(quán)限。