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

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

В этом руководстве описывается базовый синтаксис и структура правил безопасности облачного хранилища для создания полных наборов правил.

Объявление сервиса и базы данных

Правила безопасности Firebase для облачного хранилища всегда начинаются со следующего объявления:

service firebase.storage {
    // ...
}

service firebase.storage декларация прицелы правила к Cloud Storage, предотвращение конфликтов между Облачные правил и правил хранения безопасности для других продуктов , таких как облако Firestore.

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

Основные правила состоят из match заявления идентифицирующего ведер Облака хранения, заявление соответствия с указанием имени файла, и 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 .

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

В additiont к указывая на один файл, правила можно использовать подстановочные знаки , чтобы указать на какой - либо файл с заданной строкой префиксом в имени, в том числе косых черт, как в match /images/{imageId} .

В приведенном выше примере оператор матча использует {imageId} подстановочные синтаксис. Это означает , что правило применяется к любому файлу с /images/ в начале его названия, такие как /images/profilePhoto.png или /images/croppedProfilePhoto.png . Когда allow выражения в операторе матча оцениваются, то 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 взаимодействуют с этими именами файлов.

Рассмотрим ситуацию набора файлов с именами , которые все начинаются с /images/ стволовыми. Firebase Правило безопасности применяется только при совпадающем файле, поэтому контроль доступа , определенный на /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 .

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

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

Версия 1

Правила безопасности Firebase по умолчанию используют версию 1. В версии 1 рекурсивные символы подстановки соответствуют одному или нескольким элементам имени файла, а не нулю или нескольким элементам. Таким образом, match /images/{filenamePrefixWildcard}/{imageFilename=**} соответствует имя файла , как /images/profilePics/profile.png, но не /images/badge.png. Использование /images/{imagePrefixorFilename=**} вместо этого.

Рекурсивные символы подстановки должны стоять в конце оператора соответствия.

Мы рекомендуем вам использовать версию 2 из-за ее более мощных функций.

Версия 2

В версии 2 правил безопасности Firebase рекурсивные подстановочные знаки соответствуют нулю или более элементам пути. Таким образом, /images/{filenamePrefixWildcard}/{imageFilename=**} соответствует имен файлов /images/profilePics/profile.png и /images/badge.png.

Вы должны выбрать в версии 2, добавив rules_version = '2'; в верхней части ваших правил безопасности:

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

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

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 document 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 nonexistent files
      allow create: if <condition>;

      // Applies to updates to 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 any filename containing string '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches all filenames containing string `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

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

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

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

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

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

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

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

Вы можете углубить свое понимание правил безопасности Firebase для облачного хранилища:

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

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

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