このガイドは、Firebaseリアルタイムデータベースセキュリティルールに条件を追加する方法を示す、Firebaseセキュリティルールのコア言語ガイドの学習に基づいています。
リアルタイムデータベースセキュリティルールの主要な構成要素は、条件です。条件は、特定の操作を許可するか拒否するかを決定するブール式です。基本的なルールの場合、条件としてtrue
およびfalse
リテラルを使用すると、問題なく機能します。ただし、リアルタイムデータベースセキュリティルール言語を使用すると、次のようなより複雑な条件を記述できます。
- ユーザー認証を確認する
- 新しく送信されたデータに対して既存のデータを評価します
- データベースのさまざまな部分にアクセスして比較する
- 受信データを検証する
- セキュリティロジックに着信クエリの構造を使用する
$変数を使用してパスセグメントをキャプチャする
$
プレフィックスを付けてキャプチャ変数を宣言することにより、読み取りまたは書き込みのパスの一部をキャプチャできます。これはワイルドカードとして機能し、ルール条件内で使用するためにそのキーの値を格納します。
{ "rules": { "rooms": { // this rule applies to any child of /rooms/, the key for each room id // is stored inside $room_id variable for reference "$room_id": { "topic": { // the room's topic can be changed if the room id has "public" in it ".write": "$room_id.contains('public')" } } } } }
動的$
変数は、定数パス名と並行して使用することもできます。この例では、 $other
変数を使用して、 widget
title
とcolor
以外の子がないことを保証する.validate
ルールを宣言していwidget
。追加の子が作成される結果となる書き込みは失敗します。
{ "rules": { "widget": { // a widget can have a title or color attribute "title": { ".validate": true }, "color": { ".validate": true }, // but no other child paths are allowed // in this case, $other means any key excluding "title" and "color" "$other": { ".validate": false } } } }
認証
最も一般的なセキュリティルールパターンの1つは、ユーザーの認証状態に基づいてアクセスを制御することです。たとえば、アプリでサインインしたユーザーのみにデータの書き込みを許可したい場合があります。
アプリでFirebaseAuthenticationを使用している場合、 request.auth
変数には、データをリクエストしているクライアントの認証情報が含まれています。 request.auth
詳細については、リファレンスドキュメントを参照してください。
FirebaseAuthenticationはFirebaseRealtime Databaseと統合されており、条件を使用してユーザーごとにデータアクセスを制御できます。ユーザーが認証されると、Realtime Database SecurityRulesルールのauth
変数にユーザーの情報が入力されます。この情報には、一意の識別子( uid
)、Facebook IDや電子メールアドレスなどのリンクされたアカウントデータ、およびその他の情報が含まれます。カスタム認証プロバイダーを実装する場合は、ユーザーの認証ペイロードに独自のフィールドを追加できます。
このセクションでは、Firebase Realtime Database SecurityRules言語をユーザーに関する認証情報と組み合わせる方法について説明します。これら2つの概念を組み合わせることで、ユーザーIDに基づいてデータへのアクセスを制御できます。
auth
変数
認証が行われる前は、ルールで事前定義されたauth
変数はnullです。
ユーザーがFirebaseAuthenticationで認証されると、次の属性が含まれます。
プロバイダー | 使用される認証方法(「パスワード」、「匿名」、「フェイスブック」、「github」、「グーグル」、または「ツイッター」)。 |
uid | 一意のユーザーID。すべてのプロバイダーで一意であることが保証されています。 |
トークン | Firebase AuthIDトークンの内容。詳細については、 auth.token のリファレンスドキュメントを参照してください。 |
次に、 auth
変数を使用して、各ユーザーがユーザー固有のパスにのみ書き込むことができるようにするルールの例を示します。
{ "rules": { "users": { "$user_id": { // grants write access to the owner of this user account // whose uid must exactly match the key ($user_id) ".write": "$user_id === auth.uid" } } } }
認証条件をサポートするためのデータベースの構造化
通常、ルールの記述を容易にする方法でデータベースを構造化すると便利です。リアルタイムデータベースにユーザーデータを保存するための一般的なパターンの1つは、すべてのユーザーを単一のusers
ノードに保存することです。このノードの子はすべてのユーザーのuid
値です。ログインしたユーザーだけが自分のデータを表示できるようにこのデータへのアクセスを制限したい場合、ルールは次のようになります。
{ "rules": { "users": { "$uid": { ".read": "auth != null && auth.uid == $uid" } } } }
認証カスタムクレームの操作
さまざまなユーザーのカスタムアクセス制御が必要なアプリの場合、Firebase認証を使用すると、開発者はFirebaseユーザーにクレームを設定できます。これらのクレームは、ルールのauth.token
変数にauth.token
ます。 hasEmergencyTowel
カスタムクレームを利用するルールの例を次に示します。
{ "rules": { "frood": { // A towel is about the most massively useful thing an interstellar // hitchhiker can have ".read": "auth.token.hasEmergencyTowel === true" } } }
独自のカスタム認証トークンを作成する開発者は、オプションでこれらのトークンにクレームを追加できます。これらのクレームは、ルールのauth.token
変数で使用できます。
既存のデータと新しいデータ
事前定義されたdata
変数は、書き込み操作が行われる前にデータを参照するために使用されます。逆に、 newData
変数には、書き込み操作が成功した場合に存在する新しいデータが含まれています。 newData
は、書き込まれる新しいデータと既存のデータのマージ結果を表します。
たとえば、このルールでは、新しいレコードを作成したり、既存のレコードを削除したりできますが、既存のnull以外のデータに変更を加えることはできません。
// we can write as long as old data or new data does not exist // in other words, if this is a delete or a create, but not an update ".write": "!data.exists() || !newData.exists()"
他のパスのデータを参照する
ルールの基準として任意のデータを使用できます。事前定義された変数root
、 data
、およびnewData
を使用して、書き込みイベントの前後に存在するパスにアクセスできます。
/allow_writes/
ノードの値がtrue
であり、親ノードにreadOnly
フラグが設定されておらず、新しく書き込まれたデータにfoo
という名前の子がある限り、書き込み操作を許可するこの例について考えてみます。
".write": "root.child('allow_writes').val() === true && !data.parent().child('readOnly').exists() && newData.child('foo').exists()"
データの検証
データ構造の適用とデータの形式と内容の検証は、 .validate
ルールを使用して実行する必要があります。 .write
ルールは、 .write
ルールがアクセスの許可に成功した後にのみ実行されます。以下は、正規表現を使用してチェックされる1900〜 2099年のYYYY-MM-DD形式の日付のみを許可する.validate
ルール定義のサンプル.validate
。
".validate": "newData.isString() && newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"
.validate
ルールは、カスケードしない唯一のタイプのセキュリティルールです。子レコードで検証ルールが失敗した場合、書き込み操作全体が拒否されます。さらに、データが削除されると(つまり、書き込まれる新しい値がnull
)、検証定義は無視されnull
。
これらは些細なことのように思えるかもしれませんが、実際には強力なFirebaseRealtimeデータベースセキュリティルールを作成するための重要な機能です。次のルールを考慮してください。
{ "rules": { // write is allowed for all paths ".write": true, "widget": { // a valid widget must have attributes "color" and "size" // allows deleting widgets (since .validate is not applied to delete rules) ".validate": "newData.hasChildren(['color', 'size'])", "size": { // the value of "size" must be a number between 0 and 99 ".validate": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99" }, "color": { // the value of "color" must exist as a key in our mythical // /valid_colors/ index ".validate": "root.child('valid_colors/' + newData.val()).exists()" } } } }
このバリアントを念頭に置いて、次の書き込み操作の結果を確認してください。
JavaScript
var ref = db.ref("/widget"); // PERMISSION_DENIED: does not have children color and size ref.set('foo'); // PERMISSION DENIED: does not have child color ref.set({size: 22}); // PERMISSION_DENIED: size is not a number ref.set({ size: 'foo', color: 'red' }); // SUCCESS (assuming 'blue' appears in our colors list) ref.set({ size: 21, color: 'blue'}); // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate ref.child('size').set(99);
Objective-C
FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"]; // PERMISSION_DENIED: does not have children color and size [ref setValue: @"foo"]; // PERMISSION DENIED: does not have child color [ref setValue: @{ @"size": @"foo" }]; // PERMISSION_DENIED: size is not a number [ref setValue: @{ @"size": @"foo", @"color": @"red" }]; // SUCCESS (assuming 'blue' appears in our colors list) [ref setValue: @{ @"size": @21, @"color": @"blue" }]; // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate [[ref child:@"size"] setValue: @99];
迅速
var ref = FIRDatabase.database().reference().child("widget") // PERMISSION_DENIED: does not have children color and size ref.setValue("foo") // PERMISSION DENIED: does not have child color ref.setValue(["size": "foo"]) // PERMISSION_DENIED: size is not a number ref.setValue(["size": "foo", "color": "red"]) // SUCCESS (assuming 'blue' appears in our colors list) ref.setValue(["size": 21, "color": "blue"]) // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate ref.child("size").setValue(99);
Java
FirebaseDatabase database = FirebaseDatabase.getInstance(); DatabaseReference ref = database.getReference("widget"); // PERMISSION_DENIED: does not have children color and size ref.setValue("foo"); // PERMISSION DENIED: does not have child color ref.child("size").setValue(22); // PERMISSION_DENIED: size is not a number Map<String,Object> map = new HashMap<String, Object>(); map.put("size","foo"); map.put("color","red"); ref.setValue(map); // SUCCESS (assuming 'blue' appears in our colors list) map = new HashMap<String, Object>(); map.put("size", 21); map.put("color","blue"); ref.setValue(map); // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate ref.child("size").setValue(99);
残り
# PERMISSION_DENIED: does not have children color and size curl -X PUT -d 'foo' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # PERMISSION DENIED: does not have child color curl -X PUT -d '{"size": 22}' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # PERMISSION_DENIED: size is not a number curl -X PUT -d '{"size": "foo", "color": "red"}' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # SUCCESS (assuming 'blue' appears in our colors list) curl -X PUT -d '{"size": 21, "color": "blue"}' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # If the record already exists and has a color, this will # succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) # will fail to validate curl -X PUT -d '99' \ https://docs-examples.firebaseio.com/rest/securing-data/example/size.json
次に、同じ構造を見てみましょう。ただし、 .write
代わりに.validate
ルールを使用します。
{ "rules": { // this variant will NOT allow deleting records (since .write would be disallowed) "widget": { // a widget must have 'color' and 'size' in order to be written to this path ".write": "newData.hasChildren(['color', 'size'])", "size": { // the value of "size" must be a number between 0 and 99, ONLY IF WE WRITE DIRECTLY TO SIZE ".write": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99" }, "color": { // the value of "color" must exist as a key in our mythical valid_colors/ index // BUT ONLY IF WE WRITE DIRECTLY TO COLOR ".write": "root.child('valid_colors/'+newData.val()).exists()" } } } }
このバリアントでは、次の操作のいずれかが成功します。
JavaScript
var ref = new Firebase(URL + "/widget"); // ALLOWED? Even though size is invalid, widget has children color and size, // so write is allowed and the .write rule under color is ignored ref.set({size: 99999, color: 'red'}); // ALLOWED? Works even if widget does not exist, allowing us to create a widget // which is invalid and does not have a valid color. // (allowed by the write rule under "color") ref.child('size').set(99);
Objective-C
Firebase *ref = [[Firebase alloc] initWithUrl:URL]; // ALLOWED? Even though size is invalid, widget has children color and size, // so write is allowed and the .write rule under color is ignored [ref setValue: @{ @"size": @9999, @"color": @"red" }]; // ALLOWED? Works even if widget does not exist, allowing us to create a widget // which is invalid and does not have a valid color. // (allowed by the write rule under "color") [[ref childByAppendingPath:@"size"] setValue: @99];
迅速
var ref = Firebase(url:URL) // ALLOWED? Even though size is invalid, widget has children color and size, // so write is allowed and the .write rule under color is ignored ref.setValue(["size": 9999, "color": "red"]) // ALLOWED? Works even if widget does not exist, allowing us to create a widget // which is invalid and does not have a valid color. // (allowed by the write rule under "color") ref.childByAppendingPath("size").setValue(99)
Java
Firebase ref = new Firebase(URL + "/widget"); // ALLOWED? Even though size is invalid, widget has children color and size, // so write is allowed and the .write rule under color is ignored Map<String,Object> map = new HashMap<String, Object>(); map.put("size", 99999); map.put("color", "red"); ref.setValue(map); // ALLOWED? Works even if widget does not exist, allowing us to create a widget // which is invalid and does not have a valid color. // (allowed by the write rule under "color") ref.child("size").setValue(99);
残り
# ALLOWED? Even though size is invalid, widget has children color and size, # so write is allowed and the .write rule under color is ignored curl -X PUT -d '{size: 99999, color: "red"}' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # ALLOWED? Works even if widget does not exist, allowing us to create a widget # which is invalid and does not have a valid color. # (allowed by the write rule under "color") curl -X PUT -d '99' \ https://docs-examples.firebaseio.com/rest/securing-data/example/size.json
これは間の違いを示し.write
と.validate
ルールを。示されているように、これらのルールはすべて.validate
を使用して.validate
必要がありますが、 newData.hasChildren()
ルールは例外であり、削除を許可するかどうかによって異なります。
クエリベースのルール
ルールをフィルターとして使用することはできませんが、ルールでクエリパラメーターを使用することにより、データのサブセットへのアクセスを制限できます。 query.
使用しquery.
クエリパラメータに基づいて読み取りまたは書き込みアクセスを許可するルール内の式。
たとえば、次のクエリベースのルールは、ユーザーベースのセキュリティルールとクエリベースのルールを使用して、 baskets
コレクション内のデータへのアクセスをアクティブユーザーが所有するショッピングバスケットのみに制限します。
"baskets": {
".read": "auth.uid != null &&
query.orderByChild == 'owner' &&
query.equalTo == auth.uid" // restrict basket access to owner of basket
}
ルールにクエリパラメータを含む次のクエリは成功します。
db.ref("baskets").orderByChild("owner")
.equalTo(auth.currentUser.uid)
.on("value", cb) // Would succeed
ただし、ルールにパラメーターが含まれていないクエリは、 PermissionDenied
エラーで失敗します。
db.ref("baskets").on("value", cb) // Would fail with PermissionDenied
クエリベースのルールを使用して、クライアントが読み取り操作を通じてダウンロードするデータの量を制限することもできます。
たとえば、次のルールは、優先度順に、クエリの最初の1000件の結果のみに読み取りアクセスを制限します。
messages: {
".read": "query.orderByKey &&
query.limitToFirst <= 1000"
}
// Example queries:
db.ref("messages").on("value", cb) // Would fail with PermissionDenied
db.ref("messages").limitToFirst(1000)
.on("value", cb) // Would succeed (default order by key)
次のquery.
式は、リアルタイムデータベースセキュリティルールで使用できます。
クエリベースのルール式 | ||
---|---|---|
表現 | タイプ | 説明 |
query.orderByKey query.orderByPriority query.orderByValue | ブール値 | キー、優先度、または値で並べ替えられたクエリの場合はTrue。それ以外の場合はFalse。 |
query.orderByChild | ストリング ヌル | 文字列を使用して、子ノードへの相対パスを表します。たとえば、 query.orderByChild == "address/zip" です。クエリが子ノードによって順序付けられていない場合、この値はnullです。 |
query.startAt query.endAt query.equalTo | ストリング 数 ブール値 ヌル | 実行中のクエリの境界を取得します。境界セットがない場合はnullを返します。 |
query.limitToFirst query.limitToLast | 数 ヌル | 実行中のクエリの制限を取得するか、制限が設定されていない場合はnullを返します。 |
次のステップ
この条件の説明の後、ルールをより高度に理解し、次の準備が整います。
コアユースケースを処理する方法を学び、ルールを開発、テスト、および展開するためのワークフローを学びます。
- 条件の作成に使用できる事前定義されたルール変数の完全なセットについて学習します。
- 一般的なシナリオに対応するルールを作成します。
- 安全でないルールを見つけて回避する必要がある状況を確認することにより、知識を構築します。
- Firebase Local Emulator Suiteと、それを使用してルールをテストする方法について説明します。
- ルールの展開に使用できる方法を確認します。
リアルタイムデータベースに固有のルール機能の学習:
- リアルタイムデータベースにインデックスを付ける方法を学びます。
- ルールをデプロイするためのRESTAPIを確認します。