Правила безопасности Firebase для мобильного приложения в реальном времени

Question

Я строю мессенджер в реальном времени, используя Ionic / Angular и Firebase. Я использую Аутентификацию Firebase для аутентификации моих пользователей, и Firebase DB для хранения сообщений и потоков сообщений.

Моя проблема в том, какие правила безопасности следует использовать, чтобы потоки сообщений были частными, жизнеспособными и доступными для записи только двум лицам, занятым в данной цепочке сообщений.

Моя структура БД теперь выглядит так:

-chats
  --Message_thread_ID
    ---Unique_ID_generated_message by Firebase
       ----Message
       ----Sender ID
       ----Receiver ID
    ---Unique_ID_generated_message by Firebase
       ----Message
       ----Sender ID
       ----Receiver ID
  --Message_thread_ID
    ---Unique_ID_generated_message by Firebase
       ----Message
       ----Sender ID
       ----Receiver ID

Мои текущие правила безопасности Firebase:

{
  "rules": {
    ".read": "auth != null",
    ".write": false,
    "$messageThreadID": {
        ".write": "auth != null && !data.exists()",
        ".read": "auth != null"
    }
  }
}

Это работает нормально, но таким образом любой аутентифицированный пользователь сможет читать все сообщения между любым пользователем. Что не то, что я хочу. Я хочу, чтобы потоки сообщений были приватными только для двух пользователей в любой заданной теме.

Как мне реструктурировать мою БД для наилучшего оптимального решения?

PS: У меня есть способы сделать это с помощью бэкенда или сделать две копии для каждого из двух пользователей их соответствующих потоков, но эти решения выглядят по-настоящему непристойными.

Answer 1

Ваша текущая модель данных хранит только сообщения чата. Он еще не хранит информацию о том, кто является участниками каждого чата. Или хорошо ... он хранит его в некоторых сообщениях, но этого недостаточно для того, чтобы ваши правила безопасности могли его прочитать.

Итак, первым шагом является добавление в вашу модель данных о том, кто еще является членом:

members
  Message_thread_ID1
    member_uid_1: true
    member_uid_2: true
  Message_thread_ID2
    member_uid_1: true
    member_uid_3: true

Теперь у нас есть вся информация, необходимая для обновления правил безопасности.

{
  "rules": {
    ".read": "auth != null",
    ".write": false,
    "$messageThreadID": {
        ".write": "root.child('members').child($messageThreadID).child(auth.uid).exists()",
    }
  }
}

Теперь пользователь может писать в цепочку сообщений, только если он является участником этой цепочки.

Обычно вы получаете несколько таких списков поиска для различных вариантов использования вашего приложения. Например, вполне вероятно, что вы захотите показать список потоков сообщений для пользователя при его входе в систему. Чтобы сделать это эффективно, вы, вероятно, добавите список «потоков сообщений для каждого пользователя», что в значительной степени инверсия списка members выше:

threads_per_user
  member_uid_1: true
    Message_thread_ID1
    Message_thread_ID2
  member_uid_2: true
    Message_thread_ID1
  member_uid_3: true
    Message_thread_ID2

Этот тип структуры данных изначально кажется очень неестественным для разработчиков, имеющих опыт работы с реляционными / SQL, но на самом деле он довольно распространен в базах данных NoSQL.

Чтобы узнать больше:

• read NoSQL моделирование данных
• watch Firebase для разработчиков SQL
• Часы Познакомьтесь с Cloud Firestore
• см. отношение «многие ко многим» в Firebase
• см. Firebase-запрос, если child of child содержит значение