Условия написания правил безопасности Cloud Firestore

Это руководство основано на руководстве по структурированию правил безопасности и показывает, как добавлять условия в Cloud Firestore Security Rules . Если вы не знакомы с основами Cloud Firestore Security Rules , см. руководство по началу работы .

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

Аутентификация

Одним из наиболее распространенных шаблонов правил безопасности является управление доступом на основе состояния аутентификации пользователя. Например, ваше приложение может разрешить записывать данные только вошедшим в систему пользователям:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to access documents in the "cities" collection
    // only if they are authenticated.
    match /cities/{city} {
      allow read, write: if request.auth != null;
    }
  }
}

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

Если ваше приложение использует аутентификацию Firebase или Google Cloud Identity Platform , переменная request.auth содержит информацию аутентификации для клиента, запрашивающего данные. Дополнительную информацию о request.auth смотрите в справочной документации .

Проверка данных

Многие приложения хранят информацию о контроле доступа в виде полей документов в базе данных. Cloud Firestore Security Rules могут динамически разрешать или запрещать доступ на основе данных документа:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

Переменная resource относится к запрошенному документу, а resource.data — это карта всех полей и значений, хранящихся в документе. Дополнительную информацию о переменной resource смотрите в справочной документации .

При записи данных вам может потребоваться сравнить входящие данные с существующими. В этом случае, если ваш набор правил разрешает ожидающую запись, переменная request.resource содержит будущее состояние документа. Для операций update , которые изменяют только подмножество полей документа, переменная request.resource будет содержать состояние ожидания документа после операции. Вы можете проверить значения полей в request.resource , чтобы предотвратить нежелательные или противоречивые обновления данных:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure all cities have a positive population and
    // the name is not changed
    match /cities/{city} {
      allow update: if request.resource.data.population > 0
                    && request.resource.data.name == resource.data.name;
    }
  }
}

Доступ к другим документам

Используя функции get() и exists() , ваши правила безопасности могут сравнивать входящие запросы с другими документами в базе данных. Обе функции get() и exists() ожидают полностью определенных путей к документу. При использовании переменных для создания путей для get() и exists() вам необходимо явно экранировать переменные, используя синтаксис $(variable) .

В приведенном ниже примере переменная database фиксируется оператором match match /databases/{database}/documents и используется для формирования пути:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      // Make sure a 'users' document exists for the requesting user before
      // allowing any writes to the 'cities' collection
      allow create: if request.auth != null && exists(/databases/$(database)/documents/users/$(request.auth.uid));

      // Allow the user to delete cities if their user document has the
      // 'admin' field set to 'true'
      allow delete: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    }
  }
}

Для операций записи вы можете использовать функцию getAfter() для доступа к состоянию документа после завершения транзакции или пакета операций записи, но до фиксации транзакции или пакета. Как и get() , функция getAfter() принимает полностью указанный путь к документу. Вы можете использовать getAfter() для определения наборов записей, которые должны выполняться вместе как транзакция или пакет.

Доступ к лимитам звонков

Существует ограничение на количество вызовов доступа к документу для каждой оценки набора правил:

  • 10 для запросов по одному документу и запросов.

  • 20 для чтения нескольких документов, транзакций и пакетной записи. Предыдущее ограничение в 10 также применяется к каждой операции.

    Например, представьте, что вы создаете пакетный запрос на запись с тремя операциями записи и что ваши правила безопасности используют два вызова доступа к документу для проверки каждой записи. В этом случае каждая запись использует 2 из 10 вызовов доступа, а пакетный запрос на запись использует 6 из 20 вызовов доступа.

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

Подробное объяснение того, как эти ограничения влияют на транзакции и пакетную запись, см. в руководстве по обеспечению безопасности атомарных операций .

Доступ к звонкам и ценам

Использование этих функций выполняет операцию чтения в вашей базе данных, а это означает, что вам будет выставлен счет за чтение документов, даже если ваши правила отклонят запрос. Более подробную информацию о выставлении счетов см. в разделе «Цены Cloud Firestore .

Пользовательские функции

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

  • Функции могут содержать только один оператор return . Они не могут содержать никакой дополнительной логики. Например, они не могут выполнять циклы или вызывать внешние службы.
  • Функции могут автоматически получать доступ к функциям и переменным из области, в которой они определены. Например, функция, определенная в области видимости service cloud.firestore , имеет доступ к переменной resource и встроенным функциям, таким как get() и exists() .
  • Функции могут вызывать другие функции, но не могут выполняться рекурсивно. Общая глубина стека вызовов ограничена 10.
  • В правилах версии v2 функции могут определять переменные с помощью ключевого слова let . Функции могут иметь до 10 привязок let, но должны заканчиваться оператором return.

Функция определяется ключевым словом function и принимает ноль или более аргументов. Например, вы можете объединить два типа условий, использованных в примерах выше, в одну функцию:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

Использование функций в правилах безопасности делает их более удобными в обслуживании по мере роста сложности правил.

Правила — это не фильтры

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

Например, возьмем следующее правило безопасности:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

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

Интернет 
db.collection("cities").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
    });
});

Разрешено : это правило разрешает следующий запрос, поскольку where("visibility", "==", "public") гарантирует, что набор результатов удовлетворяет условию правила:

Интернет 
db.collection("cities").where("visibility", "==", "public").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
        });
    });

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

Следующие шаги