Authと一緒に使う（Auth.uid）

`match`と`allow`

どのドキュメントとコレクションに対してルールを適用するかの範囲
ドキュメントに対してmatchは1つのみしか使用不可

オペレーションに対してどのようなアクセス制御を行うかの条件式

writeはread使用せずに、それぞれ別で記述する

下層にルールは適用さてない

ドキュメントIDの指定も可能ではある

fun 関数名() {
    // 処理
    return
}

引数の型は不要で引数名のみで良い
引数は0個以上7個まで、returnは必須
関数内の処理はletから、関数の定義は10個まで

fun 関数名(0個以上7個まで) {
    let 変数名 // 10個まで
    return // 必須
}

同じ関数名の場合、ネスタしたmatchステートメント内の関数が有線されて呼び出しされる
トップレベルにも定義可能で、全範囲で呼び出しできる

resource
- resourceは要求されたドキュメントを参照
- resource.dataはドキュメントのフィールドをmapで返す
request.resource
- 変更後のデータにバリデーションを掛ける場合に使用
- 整合性を保つデータの際に使用（値の変わらないフィールド）
- リクエストが処理された後（DBに更新される前）のデータを示す

特殊なオペレーターが使用可能

a in b : bの配列にaがあるか

a is int : aがint型かどうか

一括で下層のmatchステートメントに適応したい！
→再帰ワイルドカード構文{document=**}を使用する
match users/{user}
match users/{document=**}

再帰ワイルドカード構文{document=**}使用した場合に発生し得る
競合したルールは、AND評価ではなくOR評価される

再帰ワイルドカード{document=**}の下層に異なるセキュリティルールを適用したい場合に使用する
例えば、Aというルールの下層のmatchステートメントにはBというルールを適用する

version=2 の場合のみ、コレクショングループに対してセキュリティルールが書ける
match /{paths=**}/users/{ワイルドカード名} のような場合
teams/{}/users/ や　products/{}/users 等に対してルールが適用される

以下のよにアクセス制御を意識する

書き込む値が妥当かどうかのバリデーションをかける
もちろん、サービス側でもバリデーションは必要（2重チェックさせる）