Firebase Firestore - правило безопасности, основанное на параметрах запроса «где»

Question

Я пытаюсь защитить запросы к коллекции, чтобы разрешить любой отдельный get, но разрешить list только в случае соответствия определенного ключа.

Структура базы данных выглядит следующим образом:

posts
  post1
    content: "Post 1 content"
    uid: "uid1"
  post2
    content: "Post 2 content"
    uid: "uid1"
  post3
    content: "Post 3 content"
    uid: "uid2"

Запрос Firestore, который я делаю из Vue:

// Only return posts matching the requested uid

db
  .collection("posts")
  .where("uid", "==", this.uid)

Правила безопасности, которые я хотел бы иметь, были бы примерно такими:

match /posts/{post} {
  allow get: if true // this works
  allow list: if [** the uid in the query **] != null

IВы хотите сделать это, чтобы вы могли перечислить сообщения определенного пользователя, если вы знаете его uid, но не можете перечислить все posts системы.

Есть ли способ получить доступ к запрошенному .where() в правилах безопасности или как я могу написать такое правило или структурировать мои данные в этом случае?

Соответствует и кредиты:

• По-видимому,Я могу сделать запрос по запросам limit, offset и orderBy. Но на where ничего нет. См .: # 1 & # 2 .

• Я скопировал много из этого вопроса . Я не понимаю, как принятый ответ отвечает на вопрос. Похоже, что это отвечает другому случаю, когда пользователю разрешено list посты некоторых других пользователей. Это не мой случай;в моем случае, что является публичным. Таким образом, это не отвечает на главный вопрос в моем случае, кажется.

Answer 1

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

Вместо этого рассмотрите возможность дублирования достаточного количества данных в другой коллекции, организованной так:

user-posts      (collection)
  {uid}         (document using UID as document ID)
     posts      (subcollection)
       {postId} (documents using post ID as document ID)

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

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

Также обратите внимание, что UID обычно не скрыты от пользователей, особенно если ваш веб-сайт является совместным по своей природе, и вы объединяете данные нескольких пользователей на одной странице.