08s-allow-and-deny.md.erb

---
title: Allow and Deny
slug: allow-and-deny
date: 0008/01/02
number: 8.5
points: 10
sidebar: true
photoUrl: http://www.flickr.com/photos/ikewinski/9475104376/
photoAuthor: Mike Lewinski
contents: AllowとDenyのコールバックを学習する|コールバックが呼び出される順序の理解
paragraphs: 16
version: 1.7
---

Meteorのセキュリティシステムは、変更したい場合にメソッドに変更を行う必要なく、
データベースの変更を制御することができます。

私たちは余分なプロパティを持つ投稿を装飾してその投稿のURLがすでに投稿されていたとき、特別な行動をとるような補助作業を行うために、
記事を作成する際に特別な`post`メソッドを作成する必要がありました。

一方で、記事の更新や削除するための新しいメソッドを作成する必要はありませんでした。
ユーザーがこれらのアクションを実行する権限を持っていたかどうかを確認するために必要な、`allow`と `deny`コールバックで簡単にできました。

これらのコールバックを使用すると、私たちはデータベースの変更の詳細については宣言型であること、
および幾つかの種類の更新の使用することで、できると言うことができます。
アカウントシステムと統合するという事実はおまけです。

### 複数のコールバック
必要に応じて、我々は多くの`allow`コールバックを定義することができます。

我々はただ与えられた変更のために`true`を返すためにそれらの少なくとも一つを必要としています。

それで、`Posts.insert`がブラウザから呼び出されることで(クライアントサイドのコードかコンソールからのものかは関係なく)、
サーバーはtrueを返すものが一つでもあれば`insert`は許可と判断します。
それがいずれも見つからない場合は、挿入を許可しませんし、クライアントに`403`エラーを返します。

同様に、一つ以上の`deny`コールバックを定義することができます。これらのコールバックのいずれかが`true`を返した場合は、変更がキャンセルされ、`403`が返されます。
このロジックの意味することは、`insert`が成功するには一つ以上の`allow` `insert`コールバックとすべての`deny``insert`コールバックが実行されることを意味します。

<%= diagram "allow_deny", "Note: n/e stands for Not Executed" %>

言い換えれば、Meteorは最初の`deny`で始まるコールバックリストを下に移動させ、
その後`allow`の1つが`true`を返すまで、すべてのコールバックを実行します。

このパターンの実用的な例は、2つの`allow()`コールバックを持つ可能性があり、
ポストは、1つめで現在のユーザーに属しているかどうかをチェック、もう一つで現在のユーザーが管理者権限を持つかどうかをチェックします。
現在のユーザーが管理者である場合は、それらのコールバックの少なくとも一つがtrueを返しますので、これは、彼らがどんな記事を更新することができるかが保証されます。

###レイテンシー補正

（`.update()`など）データベース変異メソッドは他のメソッドと同様に、待ち時間補償されることを忘れないでください。
だから、例えば、あなたがブラウザのコンソールから、あなたに属していない投稿を削除しようとすると、
ローカルのコレクションは、投稿が簡単に消えて表示されますが、サーバーがそのことを通知されてから実際の削除が行われるため、実際にはその瞬間に文書は削除されていません。

もちろん、この動作は、コンソールから発生する問題はありません。
(ユーザーがコンソール上でデータを台無しにしようとした場合、彼らのブラウザで何かが起りますが、こちら側に影響はしません)
ただし、これはあなたのユーザーインターフェイスに起こらないことを確認する必要があります。
たとえば、削除は許可していない文書のための削除ボタンを表示していないことを確認するために労力を割く必要があります。

ありがたいことに、あなたはクライアントとサーバの間の権限コードを共有することができますので、
（たとえば、ライブラリ関数`canDeletePost(user, post)`を書くことができ、`/lib`ディレクトリにそれを置き共有します。）
したがって余分なコードを必要としません。

### サーバー側のアクセス権

許可システムはクライアントから開始されデータベース変異に適用されることを覚えておいてください。
サーバーでは、Meteorは、__すべて__の操作が許可されていることを前提としています。

このことは、サーバー側で`deletePost`Meteorメソッドを記述した場合、あなたがクライアントから呼び出すことができ、
誰もがどんな投稿を削除することができることを意味します。
そのメソッド内のユーザー権限をチェックしない限り、実行は避けたいと思うはずです。