1

安全なデータ フィールド (ユーザーが自分自身を更新することを信頼されていない) と安全でないデータの間で Firebase テーブル/オブジェクトを構造化するためのベスト プラクティスはありますか?

たとえば、ユーザーは自分のusersオブジェクト内で自分の名前や設定を自由に変更できる必要がありますが、有料ユーザーであるかどうか、電子メールが確認されているかどうかなどの設定を自由に変更できるべきではありません。たとえば、user.nameユーザーが直接編集できる必要がありますがuser.email、独自の API を介してのみ変更する必要があります。これにより、Firebase のレコードが更新されます。

これは、基本的に必要なすべてのテーブルで見られるため、一般的な要件のようです。例: we have users、 we have projects、 we have taskswithin a project など。これらのデータ型のそれぞれについて、ユーザーが編集できるフィールドとそうでないフィールドが常に存在します。

では、どのタイプのアプローチがベストプラクティスでしょうか? 次の 2 つの可能性があります。

secure_data:
  users:
    user1:
      email:
    user2:
  projects:
  tasks:
insecure_data:
  users:
    user1:
      name:
    user2:
  projects:
  tasks:

または：

users:
  user1:
    secure:
      email:
    insecure:
      name:
projects:
   project1:
     secure:
     insecure:
tasks:

ちなみに、この回答は、上記の最初のオプションを使用する必要があることを意味しますが、この質問をより一般的に構成して、実際にベストプラクティスがあるかどうかを確認したかったのです。

4

1 に答える 1

4

ライブデモを含む、データ構造とauth に関連するセキュリティに関するトピックを含む、ベストプラクティスをカバーする完全なガイドがあります。

以前にリンクされた質問は、保護されたデータを読み取るためのユースケースを既にカバーしているため、同じ質問をしているのではなく、書き込み制限のみに関心があると仮定します。読み取り制限が必要な場合、この質問は重複しています。そのパス内のすべてのデータが読み取り可能でない限り、パスを反復またはクエリすることはできません。

書き込み制限は非常に簡単です。関連するフィールドへの書き込みアクセスのみを許可します。

たとえば、ユーザーが電子メールへの書き込みはできるが、有給ステータスはできない場合:

{
  "rules": {
     "users": {
        "$uid": {
           // allow write access to email but not paid status
           "email": ".write": "auth.uid === $uid"
        }
     }
  }
}
于 2015-10-27T18:34:47.730 に答える