2016-10-24 12 views
1

私のiOS Appでは、ユーザーはFacebookのフレンドリクエストと原則的に似たフレンドリクエストをすることができます。したがって、誰かがx人の友人を持つことができます。Firebaseのセキュリティルール - 重複した友達リクエストを防止する

ユーザーが同じユーザーに複数の友だちリクエストを送信しないようにしたいのですが、データベースルールに検証ルールを追加することでこれを行うことを望んでいました - (私はもう別のリストはまだありません)

私が持っている現在の妥当性検査のルールは、ユーザーが自分自身にフレンドリクエストを送信しないようにすることです。

以下は、 'fromUid'と 'toUid'の値が両方ともペアとして存在していないことを確認する必要があるデータベースの構造です。

"requests" : { 

     "-KUr12h72I4T2WiI4JG0" : { // autoChildId 

      "fromUid" : "etOdpR0wpKYNFrIP7BNirhCYuYo1", 
      "toUid" : "UeATHfKdjVYunsOt8L0TGxfCBTQ2" 
    } 

私は

自分自身に友達リクエストを送信してから
"requests": { 
     ".read": "auth != null", 
     "$autoID": { 
      ".validate": "newData.child('fromUid').val() != newData.child('toUid').val()" 
     } 
    }, 

をユーザーを防ぎ、どのように私は「fromUid」の値と「toUid」の値がすでに存在していないことを検証することができている現在のルール一緒にペアとして?すなわち、この友人要求はまだ行われていない。

これは、セキュリティルールのための私の失敗した試みだった:

 ".validate": "&& newData.child('fromUid').val() + newData.child('toUid').val() !== data.child('fromUid').val() + data.child('toUid').val() && newData.child('toUid').val() + newData.child('fromUid').val() !== data.child('toUid').val() + data.child('fromUid').val()" 

あなたはより多くの情報や明瞭 おかげ

答えて

3

良い(と正しいが)必要な場合は私に知らせて、データベースの構造がより多くのそして半分でください。プロジェクト。あなたのデータベース構造をひどく設計すると、特にNOSQLデータベースを扱うときに大きな問題になります。データベースの設計にあらかじめ時間を費やしていれば、後で幸せになれます。

プロジェクトを設計し、必要な操作を事前に考える必要があります。どのような役割を持つデータをどのように表示し、それに基づいてfirebaseデータベースを設計したいのですか。

私は、firebaseのドキュメントからデータを構造化することについて次のページを読むことをお勧めします。

https://firebase.google.com/docs/database/web/structure-data

あなたの問題について私は fromUidにより、データベースの構造やグループ toUidのを修正示唆しています。

{ 
    "requests": { 
     // user Ids who sent request 
     "userId1": { 
      // receiver ids 
      "userId2": true, 
      "userId3": true, 
      "userId4": true 
     }, 
     "userId2": { 
      "userId3": true, 
      "userId4": true 
     } 
    } 
} 

ここで重複した要求は不可能です。あなたがしなければならないことは、ユーザーが自分自身にリクエストを送信できなかったことだけです。

ここにこのルールがあります。

"requests": { 
    ".write": "auth != null", 
    "$senderId": { 
    "$receiverId": { 
     ".validate": "$senderId !== $receiverId" 
    } 
    } 
} 

この構造では、他の操作も簡単に行うことができます。たとえば、すべてのリクエストをfromUidで取得します。 userId1userId2などにリクエストを送信したかどうかを確認するには

+0

こんにちは。 – Edward

+0

なぜ私は自分のデータを構造化していたのか分かりません。この場合、autoByChildId()キーを追加してからtoUidおよびfromUidノードを作成する必要はありません。ユーザーのuidはユニークでイベントの1つです。この構造は物事をもっと楽にします:)、乾杯 – Edward

+0

素晴らしい!...あなたが答えを受け入れて上の矢印をクリックすると良いでしょう。これは他の人がこの答えが有用であることを知る助けになるでしょう –

関連する問題