Правила безопасности при эксплуатации трубопроводов

Хотя операции конвейера предлагают богатый набор функций, механизм правил ограничен распознаванием фильтров сравнения (например, > ) и логических фильтров (например or ), чтобы обеспечить выполнимость ограничений и безопасность.

Поддерживаемые выражения фильтра

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

  • Comparisons: eq , neq , gt , gte , lt , lte , in , arrayContains .
  • Логическое значение: and , or .

Вот несколько примеров:

  • where(eq("foo", 2))
  • where(lt("foo", 2))
  • documents("/user/1", "/user/2").where(...)

Запрос свойств

Вы можете продолжать использовать объект request для проверки аутентификации и контекста запроса, хотя некоторые свойства, доступные в стандартных запросах, не поддерживаются в операциях Pipeline.

Поддерживаемые свойства

Новый движок продолжает поддерживать следующие свойства:

  • request.auth : Доступ к данным uid пользователя и токена.
  • request.method : Определяет операцию (например, get , list ).
  • request.path : Путь к ресурсу, к которому осуществляется доступ.
  • request.time : Временная метка запроса, отображаемая на стороне сервера.

Неподдерживаемые свойства

Свойства request.query , такие как limit , offset и orderBy не поддерживаются для проверок правил операций Pipeline из-за сложности определения этих значений в многоэтапных запросах.

Обработка этапов конвейера и права доступа

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

  • allow list разрешений: Запускается на этапах collection() , collectionGroup() и database() .
  • allow get разрешений: Запускается этапом documents() , который обрабатывается аналогично пакетной операции get данных.
  • Этап литералов: Этап literals() не считывает данные из базы данных, но может повлечь за собой дополнительные затраты. Для предотвращения злоупотреблений его необходимо использовать в паре с другим этапом (например, collection() ), который может быть проверен с помощью правил.

Этапы модификации поля

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

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

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

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

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

Разрешено : Это правило разрешает следующий конвейер обработки данных, поскольку этап where(eq(field("visibility"), constant("public"))) происходит до любых этапов модификации:

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();