Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Изучите основной синтаксис правил безопасности 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, характерные для облачного хранилища: