Check out what’s new from Firebase@ Google I/O 2021, and join our alpha program for early access to the new Remote Config personalization feature. Learn more

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

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

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

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

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

service firebase.storage {
    // ...
}

Объявление service firebase.storage распространяет правила на облачное хранилище, предотвращая конфликты между правилами безопасности облачного хранилища и правилами для других продуктов, таких как 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 .

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

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

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

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 значение true, а файл images / users / user: 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.

Вы должны rules_version = '2'; на версию 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 writes to existing files
      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, характерные для облачного хранилища: