Catch up on everthing we announced at this year's Firebase Summit. Learn more

Язык правил безопасности

Правила безопасности Firebase используют гибкие, мощные, настраиваемые языки, которые поддерживают широкий диапазон сложности и детализации. Вы можете сделать свои Правила настолько конкретными или общими, насколько это имеет смысл для вашего приложения. Правила базы данных реального времени используют синтаксис, похожий на JavaScript в структуре JSON. Правила Облака Firestore и Cloud Storage использовать язык , основанный на общем Expression Language (CEL) , который основан на КВЖД с match и allow заявления , что поддержка условно предоставлена доступу.

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

Выберите продукт, чтобы узнать больше о его правилах.

Базовая структура

Cloud Firestore

Правила безопасности Firebase в Cloud Firestore и Cloud Storage используют следующую структуру и синтаксис:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

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

  • Запрос: метод или методы вызываются в allow заявление. Это методы, которые вы разрешаете запускать. Стандартные методы: get , list , create , update и delete . В read и write удобных методы позволяют широкое чтению и записи на указанном пути к базе данных или хранения.
  • Путь: База данных или временного хранения, представляется в виде пути URI.
  • Правило: allow заявление, которое включает в себя условие , которое разрешает запрос , если он имеет значение истинно.

Каждая из этих концепций подробно описана ниже.

Облачное хранилище

Правила безопасности Firebase в Cloud Firestore и Cloud Storage используют следующую структуру и синтаксис:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

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

  • Запрос: метод или методы вызываются в allow заявление. Это методы, которые вы позволяете запускать. Стандартные методы: get , list , create , update и delete . В read и write удобных методы позволяют широкое чтению и записи на указанном пути к базе данных или хранения.
  • Путь: База данных или временного хранения, представляется в виде пути URI.
  • Правило: allow заявление, которое включает в себя условие , которое разрешает запрос , если он имеет значение истинно.

Каждая из этих концепций подробно описана ниже.

База данных в реальном времени

В базе данных реального времени правила безопасности Firebase состоят из выражений, подобных JavaScript, содержащихся в документе JSON.

Они используют следующий синтаксис:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

Правило состоит из трех основных элементов:

  • Путь: Расположение базы данных. Это отражает структуру JSON вашей базы данных.
  • Запрос: Эти методы в правилах использования для предоставления доступа. В read и write правила предоставляют широкий доступ для чтения и записи, а validate правила действуют в качестве вторичного контроля доступа гранта на основе входящих или существующих данных.
  • Условие: Условие , что позволяет запрос , если он имеет значение истинно.

Конструкции правил

Cloud Firestore

Основные элементы правила в Cloud Firestore и Cloud Storage следующие:

  • service декларации: Объявляет Firebase продукт правила применяются к.
  • match блок: Определяет путь в ведре базы данных или для хранения правила применяются к.
  • allow утверждение: Обеспечивает условия для предоставления доступа, дифференцированных методами. Поддерживаемые методы включают в себя: get , list , create , update , delete , и удобные методы read и write .
  • Дополнительные function заявление: Обеспечить возможность сочетать и завернуть условия для использования в нескольких правил.

service содержит один или несколько match блоков с allow заявления , которые обеспечивают условие предоставления доступа к запросам. В request и resource переменные доступны для использования в правилах. Язык Правила Firebase безопасности также поддерживает function декларации.

Версия синтаксиса

syntax оператор указывает версию языка Firebase правил , используемых для записи источника. Последняя версия языка v2 .

rules_version = '2';
service cloud.firestore {
...
}

Если нет rules_version заявление не подается, ваши правила будут оцениваться с использованием v1 двигателя.

Услуга

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

Cloud Firestore

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

Облачное хранилище

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

Если вы определяете правила для Cloud Firestore и Cloud Storage с помощью интерфейса командной строки Firebase, вам придется хранить их в отдельных файлах.

Соответствие

match блок объявляет path шаблон , который сопоставляется с путем для запрашиваемой операции (входящий request.path ). Тело match должен иметь один или несколько вложенных match блоков, allow операторы или function декларации. Путь в вложенных match блоках относительно траектории в родительском match блоке.

path шаблон представляет собой каталог, как имя , которое может включать в себя переменные или символы. path шаблон позволяет сегмент одноканальных и многолучевых матчи сегмента. Любые переменные , связанные в path открыты в match сфере или любой вложенной сфере , где path объявлен.

Матчи против path шаблона могут быть частичными или полными:

  • Частичные матчи: path шаблон является префиксом-матч request.path .
  • Полные матчи: path соответствует шаблону всего request.path .

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

Правила в каждом полном match оцениваются , чтобы определить , следует ли разрешить запрос. Если какое-либо правило соответствия предоставляет доступ, запрос разрешается. Если подходящее правило не предоставляет доступ, запрос отклоняется.

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

В приведенном выше примере показывает, что path декларации поддерживает следующие переменные:

  • Односегментный подстановочные: Подстановочная переменная объявлена в пути, окружив переменной в фигурные скобки: {variable} . Эта переменная доступна в match заявления в качестве string .
  • Рекурсивные подстановочный: рекурсивные или несколько сегментов, подстановочные ссылки несколько сегментов пути на уровне или ниже пути. Этот подстановочный знак соответствует всем путям ниже указанного вами местоположения. Вы можете объявить его, добавив =** строки в конце переменного сегмента: {variable=**} . Эта переменная доступна в match заявления в качестве path объекта.

Разрешать

match блок содержит один или более allow заявление. Это ваши настоящие правила. Вы можете применить allow правила к одному или нескольким способам. Условия на allow оператор должен оценить, верно для облачных Firestore или Cloud Storage предоставить любой входящий запрос. Вы также можете написать allow заявление без условий, например, allow read . Если allow оператор не включает в себя условие, однако, он всегда позволяет запрос для этого метода.

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

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

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

Методика

Каждый allow оператор включает в себя метод , который предоставляет доступ для входящих запросов одного и того же метода.

Метод Тип запроса
Методы удобства
read Любой тип запроса на чтение
write Любой тип запроса на запись
Стандартные методы
get Запросы на чтение отдельных документов или файлов
list Чтение запросов на запросы и коллекции
create Напишите новые документы или файлы
update Запись в существующие документы базы данных или обновление метаданных файла
delete Удалить данные

Вы не можете перекрытием методы чтения в том же match блока или противоречащие друг другу методы записи в том же path декларации.

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

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

Функция

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

  • Функции могут содержать только один return заявление. Они не могут содержать никакой дополнительной логики. Например, они не могут выполнять циклы или вызывать внешние службы.
  • Функции могут автоматически обращаться к функциям и переменным из области, в которой они определены. Например, функция , заданная в пределах service cloud.firestore объема имеет доступ к resource переменной и встроенные функции , такие как get() и exists() .
  • Функции могут вызывать другие функции, но не могут выполнять рекурсию. Общая глубина стека вызовов ограничена 20.
  • В правилах версии 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();
    }
  }
}

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

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

Обратите внимание , как isAdmin назначение навязывает на поиск коллекции администраторов. Для ленивых вычислений , не требуя ненужных Lookups, воспользоваться короткозамыкающей природой && (AND) и || (OR) сравнения , чтобы вызвать вторую функцию только тогда , когда isAuthor показано , чтобы быть правдой (для && сравнений) или ложным (для || сравнений).

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

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

Облачное хранилище

Основные элементы правила в Cloud Firestore и Cloud Storage следующие:

  • service декларации: Объявляет Firebase продукт правила применяются к.
  • match блок: Определяет путь в ведре базы данных или для хранения правила применяются к.
  • allow утверждение: Обеспечивает условия для предоставления доступа, дифференцированных методами. Поддерживаемые методы включают в себя: get , list , create , update , delete , и удобные методы read и write .
  • Дополнительные function заявление: Обеспечить возможность сочетать и завернуть условия для использования в нескольких правил.

service содержит один или несколько match блоков с allow заявления , которые обеспечивают условие предоставления доступа к запросам. В request и resource переменные доступны для использования в правилах. Язык Правила Firebase безопасности также поддерживает function декларации.

Версия синтаксиса

syntax оператор указывает версию языка Firebase правил , используемых для записи источника. Последняя версия языка v2 .

rules_version = '2';
service cloud.firestore {
...
}

Если нет rules_version заявление не подается, ваши правила будут оцениваться с использованием v1 двигателя.

Услуга

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

Cloud Firestore

service cloud.firestore {
 // Your 'match' blocks with their corresponding 'allow' statements and
 // optional 'function' declarations are contained here
}

Облачное хранилище

service firebase.storage {
  // Your 'match' blocks with their corresponding 'allow' statements and
  // optional 'function' declarations are contained here
}

Если вы определяете правила для Cloud Firestore и Cloud Storage с помощью интерфейса командной строки Firebase, вам придется хранить их в отдельных файлах.

Соответствие

match блок объявляет path шаблон , который сопоставляется с путем для запрашиваемой операции (входящий request.path ). Тело match должен иметь один или несколько вложенных match блоков, allow операторы или function декларации. Путь в вложенных match блоках относительно траектории в родительском match блоке.

path шаблон представляет собой каталог, как имя , которое может включать в себя переменные или символы. path шаблон позволяет сегмент одноканальных и многолучевых матчи сегмента. Любые переменные , связанные в path открыты в match сфере или любой вложенной сфере , где path объявлен.

Матчи против path шаблона могут быть частичными или полными:

  • Частичные матчи: path шаблон является префиксом-матч request.path .
  • Полные матчи: path соответствует шаблону всего request.path .

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

Правила в каждом полном match оцениваются , чтобы определить , следует ли разрешить запрос. Если какое-либо правило соответствия предоставляет доступ, запрос разрешается. Если подходящее правило не предоставляет доступ, запрос отклоняется.

// Given request.path == /example/hello/nested/path the following
// declarations indicate whether they are a partial or complete match and
// the value of any variables visible within the scope.
service firebase.storage {
  // Partial match.
  match /example/{singleSegment} {   // `singleSegment` == 'hello'
    allow write;                     // Write rule not evaluated.
    // Complete match.
    match /nested/path {             // `singleSegment` visible in scope.
      allow read;                    // Read rule is evaluated.
    }
  }
  // Complete match.
  match /example/{multiSegment=**} { // `multiSegment` == /hello/nested/path
    allow read;                      // Read rule is evaluated.
  }
}

В приведенном выше примере показывает, что path декларации поддерживает следующие переменные:

  • Односегментный подстановочные: Подстановочная переменная объявлена в пути, окружив переменной в фигурные скобки: {variable} . Эта переменная доступна в match заявления в качестве string .
  • Рекурсивные подстановочный: рекурсивные или несколько сегментов, подстановочные ссылки несколько сегментов пути на уровне или ниже пути. Этот подстановочный знак соответствует всем путям ниже указанного вами местоположения. Вы можете объявить его, добавив =** строки в конце переменного сегмента: {variable=**} . Эта переменная доступна в match заявления в качестве path объекта.

Разрешать

match блок содержит один или более allow заявление. Это ваши настоящие правила. Вы можете применить allow правила к одному или нескольким способам. Условия на allow оператор должен оценить, верно для облачных Firestore или Cloud Storage предоставить любой входящий запрос. Вы также можете написать allow заявление без условий, например, allow read . Если allow оператор не включает в себя условие, однако, он всегда позволяет запрос для этого метода.

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

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

service firebase.storage {
  // Allow the requestor to read or delete any resource on a path under the
  // user directory.
  match /users/{userId}/{anyUserFile=**} {
    allow read, delete: if request.auth != null && request.auth.uid == userId;
  }

  // Allow the requestor to create or update their own images.
  // When 'request.method' == 'delete' this rule and the one matching
  // any path under the user directory would both match and the `delete`
  // would be permitted.

  match /users/{userId}/images/{imageId} {
    // Whether to permit the request depends on the logical OR of all
    // matched rules. This means that even if this rule did not explicitly
    // allow the 'delete' the earlier rule would have.
    allow write: if request.auth != null && request.auth.uid == userId && imageId.matches('*.png');
  }
}

Методика

Каждый allow оператор включает в себя метод , который предоставляет доступ для входящих запросов одного и того же метода.

Метод Тип запроса
Методы удобства
read Любой тип запроса на чтение
write Любой тип запроса на запись
Стандартные методы
get Запросы на чтение отдельных документов или файлов
list Чтение запросов на запросы и коллекции
create Напишите новые документы или файлы
update Запись в существующие документы базы данных или обновление метаданных файла
delete Удалить данные

Вы не можете перекрытием методы чтения в том же match блока или противоречащие друг другу методы записи в том же path декларации.

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

service bad.example {
  match /rules/with/overlapping/methods {
    // This rule allows reads to all authenticated users
    allow read: if request.auth != null;

    match another/subpath {
      // This secondary, more specific read rule causes an error
      allow get: if request.auth != null && request.auth.uid == "me";
      // Overlapping write methods in the same path cause an error as well
      allow write: if request.auth != null;
      allow create: if request.auth != null && request.auth.uid == "me";
    }
  }
}

Функция

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

  • Функции могут содержать только один return заявление. Они не могут содержать никакой дополнительной логики. Например, они не могут выполнять циклы или вызывать внешние службы.
  • Функции могут автоматически обращаться к функциям и переменным из области, в которой они определены. Например, функция , заданная в пределах service cloud.firestore объема имеет доступ к resource переменной и встроенные функции , такие как get() и exists() .
  • Функции могут вызывать другие функции, но не могут выполнять рекурсию. Общая глубина стека вызовов ограничена 20.
  • В правилах версии 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();
    }
  }
}

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

function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  let isAdmin = exists(/databases/$(database)/documents/admins/$(userId));
  return isAuthor || isAdmin;
}

Обратите внимание , как isAdmin назначение навязывает на поиск коллекции администраторов. Для ленивых вычислений , не требуя ненужных Lookups, воспользоваться короткозамыкающей природой && (AND) и || (OR) сравнения , чтобы вызвать вторую функцию только тогда , когда isAuthor показано , чтобы быть правдой (для && сравнений) или ложным (для || сравнений).

function isAdmin(userId) {
  return exists(/databases/$(database)/documents/admins/$(userId));
}
function isAuthorOrAdmin(userId, article) {
  let isAuthor = article.author == userId;
  // `||` is short-circuiting; isAdmin called only if isAuthor == false.
  return isAuthor || isAdmin(userId);
}

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

База данных в реальном времени

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

Расположение базы данных

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

  {
    "messages": {
      "message0": {
        "content": "Hello",
        "timestamp": 1405704370369
      },
      "message1": {
        "content": "Goodbye",
        "timestamp": 1405704395231
      },
      ...
    }
  }

Ваши правила должны отражать эту структуру. Например:

  {
    "rules": {
      "messages": {
        "$message": {
          // only messages from the last ten minutes can be read
          ".read": "data.child('timestamp').val() > (now - 600000)",

          // new messages must have a string content and a number timestamp
          ".validate": "newData.hasChildren(['content', 'timestamp']) &&
                        newData.child('content').isString() &&
                        newData.child('timestamp').isNumber()"
        }
      }
    }
  }

В приведенном выше примере показывает, в реальном времени базы данных правил поддержки $location переменной , чтобы соответствовать сегментов пути. Используйте $ префикс перед вашим сегмента пути , чтобы соответствовать вашему правилу любых дочерних узлов вдоль пути.

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

Вы также можете использовать $variable параллельно с постоянными именами путей.

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }

Метод

В базе данных реального времени существует три типа правил. Два из этих типов правил - read и write - обратиться к методу входящего запроса. validate типа правила навязывает структуры данных и проверяет формат и содержание данных. Правила выполнения .validate правила после проверки того, что .write правило предоставляет доступ.

Типы правил
.читать Описывает, разрешено ли пользователям читать данные и когда.
.записывать Описывает, разрешено ли и когда записывать данные.
.validate Определяет, как будет выглядеть правильно отформатированное значение, есть ли у него дочерние атрибуты и тип данных.

По умолчанию, если нет разрешающего правила, доступ по пути запрещен.

Условия строительства

Cloud Firestore

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

request переменной

request переменные включает в себя следующие поля и соответствующую информацию:

request.auth

Веб-токен JSON (JWT), содержащий учетные данные для аутентификации из Firebase Authentication. auth маркер содержит набор стандартных требований и любых пользовательских требований, создаваемые с помощью Firebase проверки подлинности. Узнайте больше о Firebase правил безопасности и проверке подлинности .

request.method

request.method может быть любым из стандартных методов или пользовательского метода. Методы удобства read и write существуют для упрощения написания правил , которые применяются ко всем только для чтения или все записи только стандартные методы соответственно.

request.params

В request.params включает любые данные , не связанные с request.resource , которые могут быть полезны для оценки. На практике эта карта должна быть пустой для всех стандартных методов и должна содержать нересурсные данные для пользовательских методов. Службы должны быть осторожны, чтобы не переименовывать или не изменять тип любых ключей и значений, представленных как параметры.

request.path

request.path путь для целевого resource . Путь относительно сервиса. Сегменты Path , содержащие не-URL - адрес безопасные символы , такие как / являются URL-закодирован.

resource переменной

resource является текущим значением в рамках услуги , представленной как отображение пар ключ-значение. Реферирование resource в состоянии приведет не более одного чтение значения из службы. Этот поиск будет учитываться в любой квоте ресурса, связанной с сервисом. Для get запросы, то resource будет рассчитывать только в стороне квоты на отрицают.

Операторы и приоритет операторов

Используйте приведенную ниже таблицу в качестве справочника для операторов и их соответствующего приоритета в Правилах для Cloud Firestore и Cloud Storage.

Учитывая произвольные выражения a и b , а поле f , и индекс i .

Оператор Описание Ассоциативность
a[i] a() af Индекс, вызов, доступ к полю слева направо
!a -a Унарное отрицание справа налево
a/ba%ba*b Мультипликативные операторы слева направо
a+b ab Аддитивные операторы слева направо
a>ba>=ba Операторы отношения слева направо
a in b Наличие в списке или на карте слева направо
a is type Сравнение Тип, где type может быть логический, целый, дробный, число, строка, список, карта, метка времени, длительность, путь или LatLng слева направо
a==ba!=b Операторы сравнения слева направо
a && b Условное И слева направо
a || b Условное ИЛИ слева направо
a ? true_value : false_value Тернарное выражение слева направо

Облачное хранилище

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

request переменной

request переменные включает в себя следующие поля и соответствующую информацию:

request.auth

Веб-токен JSON (JWT), содержащий учетные данные для аутентификации из Firebase Authentication. auth маркер содержит набор стандартных требований и любых пользовательских требований, создаваемые с помощью Firebase проверки подлинности. Узнайте больше о Firebase правил безопасности и проверке подлинности .

request.method

request.method может быть любым из стандартных методов или пользовательского метода. Методы удобства read и write существуют для упрощения написания правил , которые применяются ко всем только для чтения или все записи только стандартные методы соответственно.

request.params

В request.params включает любые данные , не связанные с request.resource , которые могут быть полезны для оценки. На практике эта карта должна быть пустой для всех стандартных методов и должна содержать нересурсные данные для пользовательских методов. Службы должны быть осторожны, чтобы не переименовывать или не изменять тип любых ключей и значений, представленных как параметры.

request.path

request.path путь для целевого resource . Путь относительно сервиса. Сегменты Path , содержащие не-URL - адрес безопасные символы , такие как / являются URL-закодирован.

resource переменной

resource является текущим значением в рамках услуги , представленной как отображение пар ключ-значение. Реферирование resource в состоянии приведет не более одного чтение значения из службы. Этот поиск будет учитываться в любой квоте ресурса, связанной с сервисом. Для get запросы, то resource будет рассчитывать только в стороне квоты на отрицают.

Операторы и приоритет операторов

Используйте приведенную ниже таблицу в качестве справочника для операторов и их соответствующего приоритета в Правилах для Cloud Firestore и Cloud Storage.

Учитывая произвольные выражения a и b , а поле f , и индекс i .

Оператор Описание Ассоциативность
a[i] a() af Индекс, вызов, доступ к полю слева направо
!a -a Унарное отрицание справа налево
a/ba%ba*b Мультипликативные операторы слева направо
a+b ab Аддитивные операторы слева направо
a>ba>=ba Операторы отношения слева направо
a in b Наличие в списке или на карте слева направо
a is type Сравнение Тип, где type может быть логический, целый, дробный, число, строка, список, карта, метка времени, длительность, путь или LatLng слева направо
a==ba!=b Операторы сравнения слева направо
a && b Условное И слева направо
a || b Условное ИЛИ слева направо
a ? true_value : false_value Тернарное выражение слева направо

База данных в реальном времени

Условие - это логическое выражение, которое определяет, следует ли разрешить или запретить конкретную операцию. Вы можете определить эти условия в правилах базы данных реального времени следующими способами.

Предопределенные переменные

Есть ряд полезных предварительно определенных переменных, к которым можно получить доступ внутри определения правила. Вот краткое изложение каждого:

Предопределенные переменные
Теперь Текущее время в миллисекундах с эпохи Linux. Это особенно хорошо работает для проверки временных меток, созданных с помощью пакета SDK firebase.database.ServerValue.TIMESTAMP.
корень RuleDataSnapshot , представляющий путь корня в базе данных Firebase , как она существует до попытки операции.
newData RuleDataSnapshot , представляющий данные , как она будет существовать после попытки операции. Он включает новые записываемые данные и существующие данные.
данные RuleDataSnapshot , представляющий данные , как она существовала до попытки операции.
$ переменные Путь с подстановочными знаками, используемый для представления идентификаторов и динамических дочерних ключей.
авторизация Представляет полезные данные токена аутентифицированного пользователя.

Эти переменные можно использовать в любом месте ваших правил. Например, правила безопасности ниже гарантировать , что данные , записанные в /foo/ узел должен быть строкой менее 100 символов:

{
  "rules": {
    "foo": {
      // /foo is readable by the world
      ".read": true,

      // /foo is writable by the world
      ".write": true,

      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

Правила на основе данных

Любые данные из вашей базы данных могут быть использованы в ваших правилах. Использование предопределенного переменного root , data и newData , вы можете получить доступ к любому пути, он будет существовать до или после события записи.

Рассмотрим следующий пример, который позволяет операции записи до тех пор , как значение из /allow_writes/ узел true , родительский узел не имеет readOnly установлен флаг, и есть ребенок с именем foo в недавно записанных данных:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

Правила на основе запросов

Хотя вы не можете использовать правила в качестве фильтров, вы можете ограничить доступ к подмножествам данных, используя параметры запроса в ваших правилах. Использование query. выражения в ваших правилах, чтобы предоставить доступ для чтения или записи на основе параметров запроса.

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

"baskets": {
  ".read": "auth.uid != null &&
            query.orderByChild == 'owner' &&
            query.equalTo == auth.uid" // restrict basket access to owner of basket
}

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

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

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

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

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

Например, следующее правило ограничивает доступ для чтения только первыми 1000 результатами запроса, отсортированными по приоритету:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

Следующий query. выражения доступны в правилах базы данных реального времени.

Выражения правил на основе запросов
Выражение Тип Описание
query.orderByKey
query.orderByPriority
query.orderByValue
логический Верно для запросов, упорядоченных по ключу, приоритету или значению. В противном случае неверно.
query.orderByChild нить
нулевой
Используйте строку для представления относительного пути к дочернему узлу. Например, query.orderByChild == "address/zip" . Если запрос не упорядочен дочерним узлом, это значение равно нулю.
query.startAt
query.endAt
query.equalTo
нить
количество
логический
нулевой
Извлекает границы выполняемого запроса или возвращает null, если не установлено никаких границ.
query.limitToFirst
query.limitToLast
количество
нулевой
Извлекает ограничение на выполнение запроса или возвращает null, если ограничение не установлено.

Операторы

Realtime Правило баз данных поддерживает ряд операторов можно использовать для объединения переменных в формулировке условия. Смотрите полный список операторов в справочной документации .

Создание условий

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

Для некоторых инструктивного создания простого, производство готового правил, см Основных правил безопасности .