パイプライン クエリのルールをサポートする主な目的は、既存のルールエンジンのフィルタリング機能を一致させることです。パイプライン クエリは豊富な機能を提供しますが、ルールエンジンはクエリの充足性とセキュリティを確保するために、単純なフィルタのみ認識するように制限されています。
サポートされているフィルタ式
クエリをルールで制約するには、定数に対して標準の比較演算子を使用する必要があります。ルールエンジンでは、次のフィルタタイプが認識されます。
- 等式と不等式:
eq、neq - 比較:
gt、gte、lt、lte - メンバーシップ:
in、arrayContains
次に例を示します。
where(eq("foo", 2))where(lt("foo", 2))documents("/user/1", "/user/2").where(...)
リクエストのプロパティ
引き続き request オブジェクトを使用して認証とクエリ コンテキストを検証することはできますが、標準クエリで使用できるプロパティの中には、パイプラインでサポートされていないものもあります。
サポートされているプロパティ
新しいエンジンは引き続き次のプロパティをサポートしています。
request.auth: ユーザー uid とトークンデータにアクセスします。request.method: オペレーションを識別します（get、listなど）。request.path: アクセスされているリソースのパス。request.time: リクエストのサーバーサイドのタイムスタンプ。
サポートされていないプロパティ
limit、offset、orderBy などの request.query プロパティは、マルチステージ クエリでこれらの値を特定する複雑さのため、パイプライン ルールチェックではサポートされていません。
パイプライン ステージの処理と権限
セキュリティ ルールの特定の細かなオペレーションにマッピングされるパイプライン ステージは次のとおりです。
allow list権限:collection()、collectionGroup()、database()の各ステージでトリガーされます。allow get権限:documents()ステージによってトリガーされ、getバッチ オペレーションと同様に扱われます。- フィールド変更ステージ: ルールは、派生値ではなく、保存データに対してのみ動作します。パイプラインにフィールドを変更するステージ（
AddFields、ReplaceWith、Selectなど）が含まれている場合、そのステージが検出されると、ルールエンジンはフィルタ制約の適用を停止します。 - リテラル ステージ:
literals()ステージはデータベースから読み取りませんが、費用が発生する可能性があります。不正使用を防ぐため、ルールで検証できる別のステージ（collection()など）とペアにする必要があります。