Правила Firestore

Правила безопасности Firestore определяют, кто и что вправе делать с вашими данными. Без них база открыта всем — любой, кто узнал параметры проекта, сможет читать и переписывать документы.

Например, правила позволяют разрешить создание записи только тем, кто вошёл в приложение — через почту, Google или другой способ входа.

Где задавать правила

Два варианта:

1. В настройках Firestore внутри FlutterFlow
2. В консоли Firestore

1. В настройках FlutterFlow

Базовые правила задаются прямо в билдере, в разделе Firestore Settings.

Как это устроено

Настраиваются четыре операции над документом:

• Create — создание документа в коллекции.
• Read — чтение документов.
• Write — изменение документа.
• Delete — удаление документа.

Для каждой операции доступны уровни доступа:

• Everyone — все подряд, вошедшие и нет.

• Authenticated Users — только те, кто вошёл в приложение: через почту, Google и так далее.

• Tagged Users — только те, кто указан в самом документе. Скажем, в коллекции «posts» есть поле created_by с автором записи; правило Tagged Users на этом поле разрешит читать, менять и удалять пост только его автору.

• Users Collection — доступ есть у пользователя, чей идентификатор совпадает с ID документа. Вариант имеет смысл только для коллекции «users».
• No One — операция запрещена всем.

Что применяется к новым коллекциям

Коллекция, созданная в Firestore Content Manager, получает такие правила:

• Create → Everyone — создавать документы может кто угодно.
• Read → Everyone — читать может кто угодно.
• Write → No One — изменять нельзя никому.
• Delete → No One — удалять нельзя никому.

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

Пример: свежесозданная коллекция «notes» по умолчанию открыта на чтение всем, хотя читать заметку должен только её автор. Флаг Has Private Data выведет предупреждение, и правила можно будет поправить.

Нужен полный контроль над конкретной коллекцией — отметьте Exclude: FlutterFlow перестанет генерировать для неё правило, и вы напишете своё в консоли Firestore.

Если вместе с пользователем нужно удалять и все связанные с ним записи, выберите для правила Delete уровень Tagged Users и включите соответствующую опцию каскадного удаления.

Пример

Настроим правила коллекции todos под такие требования:

• создавать задачу может только вошедший пользователь;
• видеть задачи может кто угодно;
• менять задачу может только её автор;
• удалять задачи нельзя никому.

Порядок действий:

1. В секции Firestore Rules поставьте Create — Authenticated Users.
2. Read — Everyone.
3. Write — Tagged Users. Откроется окно Tag Users:
   1. Нажмите Unset и выберите поле со ссылкой на пользователя или его идентификатором.
   2. Нажмите Save Changes.
4. Delete — No One.
5. Выкатите правила.

2. В консоли Firestore

Более сложные правила пишут прямо в консоли Cloud Firestore.

Возьмём ту же коллекцию todos, но требования жёстче:

• создать задачу может пользователь, который вошёл и подтвердил почту или телефон, и сама задача должна быть корректной;
• видеть задачи может кто угодно;
• менять задачу может только её автор, и только на корректные данные;
• удалять задачу может только её автор.

Что делать:

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;
    }
  }
}

Что здесь происходит:

1. isSignedIn() — вошёл ли пользователь.
2. verified() — подтверждена ли почта или телефон.
3. isValidItem() — не пустая ли задача.
4. create — создавать можно, если пользователь вошёл, подтверждён и задача корректна.
5. read — читать может кто угодно.
6. write — менять может автор, и только на корректные данные.
7. delete — удалять может только автор.

Выкатка правил

Нажмите Deploy.

Перед выкаткой билдер покажет, что изменилось: слева прежняя версия правил, справа новая. Проверьте и нажмите Deploy Now.

Возврат к прежним правилам

Откатиться можно в консоли Cloud Firestore:

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

Частые вопросы

При выкатке правил — ошибка «cloud resource location is not set» или «It looks like you haven't used Cloud Firestore in this project before»

Вариант 1

Вариант 2

Скорее всего, в проекте Firebase не задано «Default GCP resource location». Что делать:

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