Изучите основной синтаксис правил безопасности Firebase для языка Cloud Storage.

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Firebase Security Rules для Cloud Storage позволяют контролировать доступ к объектам, хранящимся в контейнерах Cloud Storage . Гибкий синтаксис правил позволяет создавать правила для управления любой операцией, от всех записей в контейнер Cloud Storage до операций с определенным файлом.

В этом руководстве описывается базовый синтаксис и структура Cloud Storage Security Rules для создания полных наборов правил.

Декларация услуг и баз данных

Firebase Security Rules для Cloud Storage всегда начинаются со следующего заявления:

service firebase.storage {
    // ...
}

Декларация service firebase.storage распространяет действие правил на Cloud Storage , предотвращая конфликты между Cloud Storage Security Rules и правилами для других продуктов, таких как Cloud Firestore .

Основные правила чтения/записи

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

В вашем наборе правил по умолчанию первый оператор match использует подстановочное выражение {bucket} чтобы указать, что правила применяются ко всем контейнерам в вашем проекте. Мы обсудим идею подстановочных совпадений подробнее в следующем разделе.

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all Cloud Storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Все операторы сопоставления указывают на файлы. Оператор сопоставления может указывать на конкретный файл, как в match /images/profilePhoto.png .

Подстановочные знаки

Помимо указания на один файл, Rules могут использовать подстановочные знаки для указания на любой файл с заданным строковым префиксом в имени, включая косые черты, например, match /images/{imageId} .

В приведенном выше примере оператор match использует синтаксис подстановочных знаков {imageId} . Это означает, что правило применяется к любому файлу с /images/ в начале имени, например, /images/profilePhoto.png или /images/croppedProfilePhoto.png . Когда выражения allow в операторе match оцениваются, переменная imageId преобразуется в имя файла изображения, например, profilePhoto.png или croppedProfilePhoto.png .

Из match можно сослаться на подстановочную переменную, чтобы предоставить авторизацию имени файла или пути:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Иерархические данные

Как мы уже говорили, внутри контейнера Cloud Storage нет иерархической структуры. Но используя соглашение об именовании файлов, часто включающее косые черты в именах файлов, мы можем имитировать структуру, которая выглядит как вложенная серия каталогов и подкаталогов. Важно понимать, как Firebase Security Rules взаимодействуют с этими именами файлов.

Рассмотрим ситуацию с набором файлов с именами, которые начинаются с корня /images/ . Firebase Security Rules применяются только к соответствующему имени файла, поэтому элементы управления доступом, определенные для корня /images/ не применяются к корню /mp3s/ . Вместо этого напишите явные правила, которые соответствуют различным шаблонам имен файлов:

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

При вложении операторов match путь внутреннего оператора match всегда добавляется к пути внешнего оператора match . Поэтому следующие два набора правил эквивалентны:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

Рекурсивные подстановочные знаки

В дополнение к подстановочным знакам, которые сопоставляются и возвращают строки в конце имени файла, можно объявить многосегментный подстановочный знак для более сложного сопоставления, добавив =** к имени подстановочного знака, например {path=**} :

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

Если файлу соответствуют несколько правил, результат — это OR результата всех оценок правил. То есть, если какое-либо правило, которому соответствует файл, оценивается как true , результат — true .

В приведенных выше правилах файл «images/profilePhoto.png» может быть прочитан, если либо condition , либо other_condition оцениваются как истинные, тогда как файл «images/users/user:12345/profilePhoto.png» зависит только от результата other_condition .

Cloud Storage Security Rules не каскадируются, и правила оцениваются только тогда, когда путь запроса совпадает с путем, указанным в правилах.

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

Гранулированные операции

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

Операцию read можно разбить на get и list .

Правило write можно разбить на create , update и delete :

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

Перекрывающиеся заявления о совпадении

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

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

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

Правила не являются фильтрами

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

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

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

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

filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

Правила в Cloud Storage Security Rules оценивают каждый запрос по его потенциальному результату и отклоняют запрос, если он может вернуть файл, на чтение которого у клиента нет разрешения. Запросы на доступ должны соответствовать ограничениям, установленным вашими правилами.

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

Вы можете углубить свое понимание Firebase Security Rules для Cloud Storage :

• Изучите следующую важную концепцию языка правил — динамические условия , которые позволяют вашим правилам проверять авторизацию пользователя, сравнивать существующие и входящие данные, проверять входящие данные и многое другое.

• Ознакомьтесь с типичными вариантами использования безопасности и определениями Firebase Security Rules , которые их охватывают .

Вы можете изучить примеры использования Firebase Security Rules , характерные для Cloud Storage :