Authと一緒に使う（Auth.uid）
matchとallow
match
どのドキュメントとコレクションに対してルールを適用するかの範囲
ドキュメントに対してmatchは1つのみしか使用不可
allow
オペレーションに対してどのようなアクセス制御を行うかの条件式
オペレーション
write
- create : ドキュメントの作成
- update : ドキュメントの更新
- delete : ドキュメンの削除
read
- get : 単一ドキュメントの取得
- list : クエリとコレクションの取得
許可する範囲は小さくする
writeはread使用せずに、それぞれ別で記述する
オペレションは許可制
カスケードしない
下層にルールは適用さてない
ドキュメントへのルールは、基本的にワイルドカードで指定する
ドキュメントIDの指定も可能ではある
カスタム関数を定義できる
fun 関数名() {
// 処理
return
}
引数の型は不要で引数名のみで良い
引数は0個以上7個まで、returnは必須
関数内の処理はletから、関数の定義は10個まで
fun 関数名(0個以上7個まで) {
let 変数名 // 10個まで
return // 必須
}
関数はステートメント内に書かなくて良い
同じ関数名の場合、ネスタしたmatchステートメント内の関数が有線されて呼び出しされる
トップレベルにも定義可能で、全範囲で呼び出しできる
resourceとrequest.resource
-
resource-
resourceは要求されたドキュメントを参照 -
resource.dataはドキュメントのフィールドをmapで返す
-
-
request.resource- 変更後のデータにバリデーションを掛ける場合に使用
- 整合性を保つデータの際に使用（値の変わらないフィールド）
- リクエストが処理された後（DBに更新される前）のデータを示す
三項演算子を使用できる
inとis
特殊なオペレーターが使用可能
in
a in b : bの配列にaがあるか
is
a is int : aがint型かどうか
基本的に下層のmatchステートメントにはカスケードされない
一括で下層のmatchステートメントに適応したい！
→再帰ワイルドカード構文{document=**}を使用する
match users/{user}
match users/{document=**}
ルールの競合
再帰ワイルドカード構文{document=**}使用した場合に発生し得る
競合したルールは、AND評価ではなくOR評価される
{allChildren=**}
再帰ワイルドカード{document=**}の下層に異なるセキュリティルールを適用したい場合に使用する
例えば、Aというルールの下層のmatchステートメントにはBというルールを適用する
コレクショングループに対するmatchステートメント
version=2 の場合のみ、コレクショングループに対してセキュリティルールが書ける
match /{paths=**}/users/{ワイルドカード名} のような場合
teams/{}/users/ や products/{}/users 等に対してルールが適用される
アクセス制御
以下のよにアクセス制御を意識する
- だれが所有者なのか
- だれが見ることができるのか（read）
- だれが書き込みできるのか（write）
値の妥当性
書き込む値が妥当かどうかのバリデーションをかける
もちろん、サービス側でもバリデーションは必要（2重チェックさせる）