Firestore Правило заблокированных пользователей - PullRequest
1 голос
/ 25 сентября 2019

Я уже давно ищу ответ на этот вопрос,

Просто у меня есть приложение для Android, это приложение позволяет пользователям писать или читать в / из базы данных, которая является Firestore

У меня есть коллекция с именем BlockList, которая должна содержать пользователей uid в качестве имени документа и значение поля с именем userUid, цель этой коллекции - отклонить любой запрос «только» на запись для пользователей, которыеплохо себя вести в приложении.Другими словами, я ищу правило firestore, позволяющее пользователям в BlockList читать только то, что совместно используется в приложении, и запрещать все операции записи, которые они пытаются выполнить.

Я уже проверил эти правила, но он не работает, он не позволяет выполнять операции чтения или записи, даже если пользователь не подключен к BlockList

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
   function isBlackListed() {
      return exists(/databases/$(database)/BlockList/$(request.auth.uid))
    }
    match /{document=**} {
      allow read, write: if request.auth != null && !isBlackListed();
    }
  }
}


----------


rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
         allow write: if !exists(/databases/$(database)/documents/BlockList/$(request.auth.uid))

  }
}

Обновление

Благодаря ответу Марка мне удалось все сделать правильно Рабочее правило

 match /Posts/{document=**}{
      allow write :if !exists(/databases/$(database)/documents/BlockList/$(request.auth.uid))
      allow read :if request.auth.uid != null;
}

Ответы [ 2 ]

0 голосов
/ 25 сентября 2019

не знаю, правильно ли я понял вашу проблему, и было бы полезно увидеть ваши правила, которые вы пробовали до сих пор, но я думаю, что это должно работать:

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      // Make sure a write to all documents is only allowed when
      // the current user has no document in BlockList collection
      allow write: if !exists(/databases/$(database)/documents/BlockList/$(request.auth.uid))
    }
  }
}

Я проверил это с моимэкземпляр пожарного магазина, и это выглядит нормально для меня.Конечно, вам, скорее всего, нужно будет указать документы лучше, чем подстановочный знак.

Неважно, какие данные у вас есть в документах BlockList, если в коллекции BlockList есть документ с userUid в качестве имени документа.

Я создал два документа (которые представляют пользователей)в коллекции BlockList.

two users in BlockList

Теперь я пытаюсь записать в свою таблицу турниров, в которой есть упомянутый security.rule, с помощью метода «Обновление» симулятора (с предоставленными учетными данными аутентификации, конечно)

blocked by rule because user is in BlockList

При удалении пользователя "8Zvq1fpWl2S0h1t7bIxNoxDcucn1" из BlockList и повторного использования симулятора, я получаю:

allowed by second rule

Резюме: для меня это выглядит довольно неплохо.

0 голосов
/ 25 сентября 2019

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

Frontend Solution

Когда пользователь аутентифицируется в вашем приложении, отправьте запрос, чтобы узнать, есть ли этот uid в коллекции BlockList.Если он существует, установите в своем приложении логический флаг, на который ссылаются все вызовы БД, прежде чем разрешить выполнение вызова.

Внутреннее решение

Поскольку вfrontend, вы захотите соединить проверку внешнего интерфейса с бэкэнд-безопасностью.

Изменения, которые пытается сделать пользователь, могут быть размещены в «триггерном документе», который затем выполняет облачная функция в backend onWrite.

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

...