Device Sync 互換の権限
Device Sync（フレキシブルモード）を使用する場合、 権限 システムを使用する際に特別な考慮事項があります。
一般的な権限モデルを使用して Flexible Sync を設定するためのガイドについては、Device Sync 権限ガイドを参照してください。
重要
Flexible Sync はカスタム照合を無視します
Flexible Sync は、Atlas の MongoDB コレクションで構成したカスタム照合を無視します。 代わりに、同期サブスクリプションまたは権限を評価するときに、同期されたコレクションは常に {locale: "simple"}を使用します。
同期互換ロール
Device Sync（フレキシブルモード）が有効な場合、割り当てられたロールはSync に互換性がなければなりません。 ロールが同期と互換性がなく、かつ「apply when」と評価された場合、他のロールは考慮されません。アクセスは拒否されます。
次の条件のいずれかに当てはまる場合、ロールは同期と互換性がありません。
document_filters.readまたはdocument_filters.writeは未定義です。ドキュメント フィルター、挿入、または削除の式。
クエリ可能なフィールドではないフィールドを参照します
%%true、%%false、%%values、%%environment、または%%user以外の展開を使用する%function演算子を使用します
最上位の
read、最上位のwrite、またはフィールドレベルの権限は、ブール値リテラルではありません（trueまたはfalse）。_idフィールドにはフィールドレベルの権限が指定されています。
同期互換式
Device Sync が有効になっている場合、式はデータモデルのクエリ可能なフィールドのみを参照するようになります。 ロールが他のフィールドを参照する場合は、Sync との互換性がなくなり、Device Sync では使用できなくなります。
同期対応アプリは、特定のドキュメントがクエリされる前に、同期セッションの開始時にロールを割り当てるため、"apply when" 式でドキュメントやそのフィールド値を参照することはできません。
同期に互換性のある拡張機能
Device Sync を使用する場合、一部の展開はサポートされません。 次の表は、「apply when」またはルール式のいずれかで、どの展開が同期と互換性があるかを示しています。
展開 | "apply when" で を使用できますか？ | ルール式で使用できますか？ |
|---|---|---|
はい | はい | |
はい | はい、重要な考慮事項を含みます | |
No | No | |
はい | はい、重要な考慮事項を含みます | |
いいえ。 これらの展開は ドキュメントを参照します。 App Services はセッションの開始時に「apply when」式を評価するため、評価するドキュメントはありません。 | いいえ。 これらを展開すると、ドキュメントのクエリ対象以外のフィールドにアクセスする可能性がありますが、これはアクセスできません。 | |
No | No | |
はい | はい | |
はい | いいえ。App Services はセッションの開始時に展開を展開するため、関数はドキュメントごとに動作しません。 | |
はい | はい | |
はい | はい。 | |
はい | はい |
重要
App Services は、前回のセッション以降にロールに関する変更があった場合、クライアントをリセットします。
セッションの開始時に、App Services は "apply when"、 document_filters.read 、およびdocument_filters.write式のすべての展開を展開し、結果を保存します。 これは、次の影響を持ちます。
セッション中に値が変更された場合、App Services はセッションの開始時に使用されていた値を引き続き使用します。
次のセッションでは、 の値がこのセッションの開始時のものと異なる場合、App Services はクライアントをリセットします。
読み取りルールと書込みルールでは
%function演算子は使用できません。 関数はドキュメントごとに動作しません。ユーザー オブジェクトには権限情報（「このユーザーはどのドキュメント ID がアクセスできるか」など）を保存できません。 変更は次のユーザー セッションまで再評価されず、更新によってクライアントがリセットされます。
権限の変更
前回の同期セッション以降にユーザーの権限が変更された場合、同期によってクライアントのリセットがトリガーされ、新しい権限が適用されたすべてのデータが再ダウンロードされます。
次の状況では、ユーザーの権限が変更される可能性があります。
データソースの構成を更新してルールを変更しました。
ルールはカスタム ユーザー データを参照して権限を動的に決定します。そのカスタム ユーザー データの値は、前回の同期セッション以降に変更されました。
次の場合は、クライアントリセットはトリガーされません。
App Services スキーマに新しいコレクションを追加し、新しい名前空間の権限を定義するか、デフォルト ロールを使用します。 以前に権限が適用されていないため、これによってクライアント リセットはtriggerされません。
新しいスキーマと同じドラフトで新しいコレクションのカスタム権限を構成する。 逆に、スキーマを配置した後に権限の変更を使用して配置案を配置すると、クライアントがリセットされます。これは、初期配置でデフォルトの権限が適用されていたためです。
統合ルール システム
2023 年 2 月 23 日より前は、Device Sync（フレキシブル モード）ルールはSync 構成のpermissionsフィールドに存在していました。 これらの権限は、非同期権限と同じ構成ファイルに存在するようになりました。
古い権限システム用に構成されたアプリをインポートすると、App Services は権限を新しい統合ルール システムに自動的に移行します。 アプリを手動で移行する必要はありません。 古いアプリ構成がある場合は、移行された構成をインポートして再エクスポートできます。
参考として、移行では次の変更が行われます。
permissions.defaultRolesをdata_sources/<data-source-name>/のデータソース構成ディレクトリ内のdefault_rule.jsonファイルに移動します。コレクション固有のルールを
data_sources/<data-source-name>/<database-name>/<collection-name>/のそれぞれのコレクション構成ディレクトリにあるrules.jsonファイルに移動します。defaultRolesの名前をrolesに変更します。applyWhenの名前をapply_whenに変更します。同期
readとwriteをdocument_filters.readとdocument_filters.writeに移動します。document_filters.readとdocument_filters.writeの両方が定義されていることを確認します。ユースケースに合わせて調整して、以下をロールに追加します。 使用できるのは、
trueまたはfalseのみです。 一般的には、trueが必要です。document_filtersは、読み取りおよび書込みアクセスをドキュメントごとのレベルで制限します。"read": true, "write": true, "insert": true, "delete": true, "search": true