Правила Firestore

Правила безопасности Firestore необходимы для защиты данных Firebase от потенциально вредоносных пользователей. Эти правила не только повышают безопасность, но и дают вам контроль над доступом к данным в приложении. С помощью правил Firestore вы можете устанавливать ограничения, гарантируя, что только авторизованные пользователи смогут взаимодействовать с определенными данными.

Например, вы можете настроить правила Firestore так, чтобы создание записи о приеме было разрешено только аутентифицированным пользователям, таким как те, кто вошел в систему по электронной почте, через Google Sign-in или другие методы аутентификации.

подсказка

Если вы новичок в правилах Firestore, ознакомьтесь с обзором по Началу работы с правилами Firestore.

Создание правил Firestore

Существует два способа установки правил Firestore:

1. С помощью настроек Firestore в FlutterFlow
2. С помощью консоли базы данных Firestore

1. С помощью настроек Firestore в FlutterFlow

Для настройки базовых правил вы можете использовать Firestore Setting, доступный непосредственно в FlutterFlow.

Обзор правил Firestore в FlutterFlow

Вы можете контролировать следующие операции, которые можно выполнять с документом:

• Create: Разрешить пользователям создавать новый документ в коллекции.
• Read: Разрешить пользователям читать документы в коллекции.
• Write: Разрешить пользователям обновлять документ коллекции.
• Delete: Разрешить пользователям удалять документ коллекции.

Правила по умолчанию

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

• Everyone: Это предоставляет доступ всем пользователям, как аутентифицированным, так и неаутентифицированным, позволяя им создавать, читать, обновлять и удалять документы.

• Authenticated Users: Доступ ограничен только аутентифицированными пользователями, такими как те, кто вошел в систему по электронной почте, через Google Sign-in и т. д. Любой пользователь, вошедший в приложение, теперь может создавать, читать, обновлять и удалять документы.

• Tagged Users: Разрешить пользователям читать/обновлять/удалять документ, если они помечены в этом документе. Например, предположим, есть коллекция "posts" с полем created_by, представляющим пользователя, создавшего пост. Тогда правило "Tagged User" можно установить на поле created_by, чтобы разрешить доступ (чтение/обновление/удаление) к посту только если вошедший пользователь является его создателем.

• Users Collection: Разрешить пользователям, чей идентификатор аутентификации совпадает с идентификатором документа. Совет: Этот вариант применим только к коллекции 'users'.
• No One: Никому не разрешено создавать/читать/обновлять/удалять документ.

Примечание

Для 'Tagged Users' документ должен содержать поле, которое может быть либо ссылкой на пользователя, либо строкой с идентификатором пользователя.

Правила по умолчанию для новых коллекций

При создании новой коллекции в Firestore Content Manager к коллекции применяются следующие правила по умолчанию:

• Create -> Everyone: Все пользователи могут создавать документ.
• Read -> Everyone: Все пользователи могут читать документы.
• Write -> No One: Никто не может обновлять документ.
• Delete -> No One: Никто не может удалять документ.

Правила по умолчанию

Правило по умолчанию подходит для начала работы, но перед запуском приложения подумайте об ограничении доступа к коллекциям, которые потенциально содержат личную информацию пользователя. Чтобы помочь вам с этим, мы помечаем такие коллекции как 'Has Private Data'. Это отобразит предупреждение о необходимости обновления правила и ограничения доступа.

Например, новая коллекция 'notes' по умолчанию позволяет всем читать все заметки. В реальности только пользователь, создавший заметку, должен иметь возможность ее читать. Но поскольку мы пометили ее как 'Has Private Data', появится предупреждение, как показано ниже, и вы сможете изменить правила, чтобы разрешить чтение заметки только ее создателю.

Предупреждение Firestore

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

к сведению

Чтобы правила вступили в силу, их необходимо развернуть. Нажмите кнопку Deploy, и вы увидите развернутые правила в Firebase Console > Firebase Database > Rules.

При удалении пользователя из вашего приложения вы, возможно, захотите удалить все связанные с ним записи и данные. Для этого сначала установите 'Tagged Users' для правила удаления, а затем отметьте опцию ().

Пример: Как использовать правила Firestore?

Давайте рассмотрим пример настройки правил для коллекции todos в соответствии со следующими требованиями:

• Только аутентифицированные пользователи должны иметь возможность создавать элемент Todo.
• Все пользователи (аутентифицированные и неаутентифицированные) могут просматривать все элементы Todo.
• Только пользователь, создавший элемент Todo, может его обновить.
• Никто не может удалить элемент Todo.

Для настройки правил Firestore в соответствии с указанными требованиями:

1. В разделе Firestore Rules установите Create в Authenticated Users.
2. Установите Read в Everyone.
3. Установите Write в Tagged Users. Это откроет всплывающее окно Tag Users. 2. В выпадающем списке нажмите Unset и выберите поле, содержащее либо ссылку на пользователя, либо его идентификатор. 5. Нажмите Save Changes.
4. Установите Delete в No One.
5. Теперь вы можете развернуть правила.

предупреждение

Правила, установленные в приведенных примерах, предназначены для упрощения. Вы должны тщательно понять свои требования и настроить правила соответственно.

2. С помощью консоли базы данных Firestore

Для настройки более расширенных или пользовательских правил вы можете использовать консоль Firebase Cloud Firestore.

Давайте рассмотрим пример настройки правил для коллекции todos в соответствии со следующими требованиями:

• Чтобы создать элемент Todo, пользователь должен быть аутентифицирован и подтвержден по электронной почте или телефону, и элемент должен быть действительным Todo.
• Все пользователи (аутентифицированные и неаутентифицированные) могут просматривать все элементы Todo.
• Только пользователь, создавший элемент Todo, может обновить его с действительными деталями Todo.
• Только пользователь, создавший элемент Todo, может его удалить.

Для настройки правил Firestore в соответствии с указанными требованиями:

1. Откройте консоль Firebase вашего проекта и нажмите на Firestore Database в левом меню.
2. Выберите вкладку Rules.
3. Вставьте следующий код и нажмите Publish.

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    
    // 1.
    function isSignedIn() {
      return request.auth != null;
    }
    
    // 2.
    function verified() {
      return request.auth.token.email_verified || request.auth.token.phone_number;
    }
    
    // 3.
    function isValidItem() {
      return request.resource.data.name.size() > 0 ;
    }
  
    match /todos/{document} {
      // 4.
      allow create: if isSignedIn() && verified() && isValidItem();
      // 5.
      allow read: if true;
      // 6.
      allow write: if isValidItem() && resource.data.created_by == /databases/$(database)/documents/users/$(request.auth.uid);
      // 7.
      allow delete: if resource.data.created_by == /databases/$(database)/documents/users/$(request.auth.uid);
    }

    match /users/{document} {
      allow create: if request.auth.uid == document;
      allow read: if true;
      allow write: if request.auth.uid == document;
      allow delete: if false;
    }

    match /{document=**} {
      allow read, write: if
          request.time < timestamp.date(2022, 3, 4);
    }
  }
}

Вот краткий обзор того, что происходит в приведенном выше коде:

1. isSignedIn(): Проверяет, аутентифицирован ли пользователь.
2. verified(): Проверяет, подтвержден ли пользователь по электронной почте или телефону.
3. isValidItem(): Проверяет, не пустой ли элемент Todo.
4. create: Разрешить создание элемента Todo только если пользователь аутентифицирован, подтвержден и создал действительный элемент Todo.
5. read: Разрешить всем пользователям просматривать все элементы Todo.
6. write: Разрешить обновление элемента Todo с действительными деталями пользователю, который его создал.
7. delete: Разрешить удаление элемента Todo пользователю, который его создал.

Развертывание

Чтобы развернуть правила Firestore, просто нажмите кнопку Deploy.

Перед окончательным развертыванием новых правил появится всплывающее окно с просьбой просмотреть изменения. Здесь вы можете проверить разницу между версиями до и после для правил Firestore, а затем нажать Deploy Now.

предупреждение

• Вы должны развертывать правила каждый раз при их изменении.
• Перед публикацией приложения убедитесь, что вы удалили правила Firestore по умолчанию, такие как 'allow read, write: if request.time < timestamp.date(2024, 5, 31);' и вышли из тестового режима.

Возврат к предыдущим правилам

Вы можете вернуться к предыдущему состоянию правил с помощью консоли Firebase Cloud Firestore:

1. Откройте консоль Firebase вашего проекта и нажмите на Firestore Database в левом меню.
2. Выберите вкладку Rules.
3. Выберите и скопируйте предыдущее правило из левого меню.
4. Выберите текущее правило из левого меню и вставьте предыдущее.
5. Нажмите Publish.

Подробнее

Узнайте больше о создании пользовательских правил Firestore.

Часто задаваемые вопросы

Получение ошибки "cloud resource location is not set", "It looks like you haven't used Cloud Firestore in this project before" или красного предупреждения при развертывании правил.

Ошибка-1

Ошибка-2

Если вы столкнулись с такими проблемами, вероятно, 'Default GCP resource location' не установлен в вашем проекте Firebase. Чтобы исправить это:

1. Сначала убедитесь, что вы настроили Cloud Firestore
2. Затем перейдите по второй ссылке (из ошибки) и установите расположение ресурса GCP.

Выделенная ссылка

Установите ссылку в Firebase Console > General Settings > Default GCP Resource Location