2017-10-21 13 views
0

リアルタイムDBではファンアウト書き込みを行っているときに、セキュリティルール内のnewData().parent().parent()...parent()経由で新しいデータがさまざまなパスに書き込まれるのを確認できました。セキュリティルールの異なるコレクション内の新しい文書をチェックする方法は?

const fanout = { 
    'users/user_a': { 
    username: 'foobar' 
    }, 

    'usernames': { 
    'foobar': 'user_a' 
    } 
}; 

firebase.update(fanout); 

そして、このようなセキュリティ上の何か:Firestoreのセキュリティルールでこれを行う方法があるかどう

"rules": { 
    "users": { 
    $user_id: { 
     "username": { 
     ".validate": "newData.parent().parent().parent().child('usernames').child(newData.val()).val() == auth.uid; 
     } 
    } 
    }, 

    "usernames": { 
    "$username": { 
     ".validate": "newData.parent().parent().child('users').child(auth.uid).child('username').val() == $username" 
    } 
    } 
} 

の場合は不思議でしたか?私はexists()の機能を見たことがありますが、それは書かれようとしているものではなく、既存のドキュメントのためだけです。

答えて

0

残念ながら現在、Cloud Firestoreのルールでは同等の能力はありません。 request.resource.dataを使用して、要求に書き込まれているデータを調べることができますが、バッチ書き込みはルールで別の要求として扱われ、newDataのようなすべての書き込みの正味の効果をリアルタイムデータベースで調べる方法はありません。私たちはこれをCloud Firestoreに将来追加する予定です。

usersRef.where('username', '==' 'foobar').get()クエリを実行して特定のユーザー名を取得できるので、この特定のユースケースはファンアウトなしで解決できる可能性があります。

+0

ユーザーとユーザー名を保存する2つの別々のトランザクションを持つと、データ品質の問題が発生する可能性があります(ユーザーが突然インターネットを失ったりアプリケーションを終了したために2番目のトランザクションが保存されない場合など)。これらの全く同じ理由により、私の書き込みの90%がバッチです。回避策として、それらのすべての書き込みは、私にとって理想的ではないクラウド機能で生きています。私は、Cloud Firestoreの機能がすぐに叶うことを願っています!ありがとう! – rmmmp

+0

申し訳ありませんが、私は本当に不十分に説明しました。私はあなたが "usernames"コレクションを取り除き、 "users"に直接問い合わせることで、ファンアウトを避けることができ、2つの異なる場所に書き込んで2つのトランザクションを使う必要がないと言うことを意味しました。 –

+0

しかし、ユーザー名がユーザーごとに一意であることを確認するにはどうすればよいですか?私はユーザー名を変更可能にしたいので、キーとして作成する予定はありません。 – rmmmp

関連する問題