Google is committed to advancing racial equity for Black communities. See how.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Poznaj podstawową składnię języka reguł zabezpieczeń Firebase dla Cloud Storage

Reguły bezpieczeństwa Firebase dla Cloud Storage pozwalają kontrolować dostęp do obiektów przechowywanych w zasobnikach Cloud Storage. Elastyczna składnia reguł umożliwia tworzenie reguł kontrolujących dowolne operacje, od wszystkich zapisów do zasobnika pamięci masowej po operacje na określonym pliku.

W tym przewodniku opisano podstawową składnię i strukturę reguł bezpieczeństwa pamięci masowej, aby utworzyć kompletne zestawy reguł.

Deklaracja usługi i bazy danych

Reguły zabezpieczeń Firebase dla Cloud Storage zawsze zaczynają się od następującej deklaracji:

service firebase.storage {
    // ...
}

Deklaracja service firebase.storage ogranicza reguły do ​​Cloud Storage, zapobiegając konfliktom między regułami bezpieczeństwa magazynu a regułami dla innych produktów, takich jak Cloud Firestore.

Podstawowe zasady odczytu / zapisu

Podstawowe reguły składają się z instrukcji match identyfikującej zasobniki pamięci, instrukcji dopasowania określającej nazwę pliku oraz wyrażenia allow szczegółowo opisują, kiedy odczyt określonych danych jest dozwolony. wyrażenia allow określają metody dostępu (np. odczyt, zapis) oraz warunki, w których dostęp jest dozwolony lub zabroniony.

W Twoim domyślnym zestawie reguł pierwsza instrukcja match używa wyrażenia wieloznacznego {bucket} aby wskazać, że reguły mają zastosowanie do wszystkich zasobników w Twoim projekcie. W następnej sekcji omówimy dokładniej ideę dopasowań wieloznacznych.

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

Wszystkie stwierdzenia dopasowania wskazują na pliki. Instrukcja dopasowania może wskazywać na określony plik, na przykład match /images/profilePhoto.png .

Dopasuj symbole wieloznaczne

Oprócz wskazywania na pojedynczy plik, Reguły mogą używać symboli wieloznacznych do wskazywania dowolnego pliku z danym prefiksem w nazwie, w tym ukośnikami, jak w match /images/{imageId} .

W powyższym przykładzie instrukcja match używa składni wieloznacznej {imageId} . Oznacza to, że reguła ma zastosowanie do każdego pliku z /images/ na początku nazwy, na przykład /images/profilePhoto.png lub /images/croppedProfilePhoto.png . Gdy allow wyrażeń w rachunku meczu są wyliczone, imageId zmienna będzie rozwiązać do nazwy pliku obrazu, takich jak profilePhoto.png lub croppedProfilePhoto.png .

W match można odwołać się do zmiennej wieloznacznej, aby podać nazwę pliku lub autoryzację ścieżki:

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

Dane hierarchiczne

Jak powiedzieliśmy wcześniej, w zasobniku Cloud Storage nie ma struktury hierarchicznej. Ale używając konwencji nazewnictwa plików, często zawierającej ukośniki w nazwach plików, możemy naśladować strukturę, która wygląda jak zagnieżdżona seria katalogów i podkatalogów. Ważne jest, aby zrozumieć, w jaki sposób reguły zabezpieczeń Firebase współdziałają z tymi nazwami plików.

Rozważmy sytuację z zestawem plików, których nazwy zaczynają się od /images/ stem. Reguły bezpieczeństwa Firebase mają zastosowanie tylko do pasującej nazwy pliku, więc kontrola dostępu zdefiniowana w /images/ stem nie ma zastosowania do /mp3s/ stem. Zamiast tego napisz wyraźne reguły pasujące do różnych wzorców nazw plików:

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

Podczas zagnieżdżania instrukcji match , ścieżka instrukcji match wewnętrznego jest zawsze dołączana do ścieżki instrukcji match zewnętrznego. Dlatego następujące dwa zestawy reguł są równoważne:

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/croppedProfilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

Rekursywne symbole wieloznaczne dopasowania

Oprócz symboli wieloznacznych, które dopasowują i zwracają ciągi znaków na końcu nazwy pliku, w celu bardziej złożonego dopasowania można zadeklarować wielosegmentowy symbol wieloznaczny, dodając =** do nazwy symbolu wieloznacznego, na przykład {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>;
  }
}

Jeśli do pliku pasuje wiele reguł, wynikiem jest OR wyniku wszystkich ocen reguł. Oznacza to, że jeśli jakakolwiek reguła, do której pasuje plik, evaluje na true , wynik jest true .

W powyższych zasadach plik „images / profilePhoto.png” można odczytać, jeśli condition lub other_condition wartość true, podczas gdy plik „images / users / user: 12345 / profilePhoto.png” podlega tylko wynikowi other_condition .

Reguły zabezpieczeń magazynu nie są kaskadowe, a reguły są oceniane tylko wtedy, gdy ścieżka żądania jest zgodna ze ścieżką z określonymi regułami.

Wersja 1

Reguły zabezpieczeń Firebase domyślnie używają wersji 1. W wersji 1 rekursywne symbole wieloznaczne pasują do co najmniej jednego elementu nazwy pliku, a nie do zera lub większej liczby elementów. Dlatego match /images/{filenamePrefixWildcard}/{imageFilename=**} dopasowuje nazwę pliku, na przykład /images/profilePics/profile.png, ale nie /images/badge.png. Zamiast tego użyj /images/{imagePrefixorFilename=**} .

Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.

Zalecamy używanie wersji 2 ze względu na jej bardziej zaawansowane funkcje.

Wersja 2

W wersji 2 reguł zabezpieczeń Firebase rekursywne symbole wieloznaczne pasują do zera lub większej liczby elementów ścieżki. Dlatego /images/{filenamePrefixWildcard}/{imageFilename=**} odpowiada nazwom plików /images/profilePics/profile.png i /images/badge.png.

Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2'; u góry reguł bezpieczeństwa:

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

Możesz mieć co najwyżej jeden rekursywny symbol wieloznaczny na każdą instrukcję dopasowania, ale w wersji 2 możesz umieścić ten symbol w dowolnym miejscu w instrukcji dopasowania. Na przykład:

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

Granularne operacje

W niektórych sytuacjach warto podzielić read i write na bardziej szczegółowe operacje. Na przykład Twoja aplikacja może chcieć wymusić inne warunki podczas tworzenia pliku niż podczas jego usuwania.

Operację read można podzielić na get i list .

Regułę write można podzielić na create , update i 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>;
    }
  }
 }
}

Pokrywające się stwierdzenia dopasowania

Nazwa pliku może pasować do więcej niż jednej instrukcji match . W przypadku, gdy wiele wyrażeń allow pasuje do żądania, dostęp jest dozwolony, jeśli którykolwiek z warunków jest 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;
    }
  }
}

W powyższym przykładzie wszystkie odczyty i zapisy w plikach z ciągiem /images/ dowolnym miejscu w nazwie pliku będą dozwolone, ponieważ druga reguła jest zawsze true , nawet jeśli pierwsza reguła jest zawsze false .

Reguły nie są filtrami

Po zabezpieczeniu danych i rozpoczęciu wykonywania operacji na plikach należy pamiętać, że reguły bezpieczeństwa nie są filtrami. Nie można wykonywać operacji na zbiorze plików zgodnych ze wzorcem nazwy pliku i oczekiwać, że Magazyn będzie miał dostęp tylko do plików, do których dostęp ma bieżący klient.

Na przykład weźmy następującą regułę bezpieczeństwa:

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

Odmowa : ta reguła odrzuca następujące żądanie, ponieważ zestaw wyników może zawierać pliki, w których contentType nie ma wartości image/png :

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

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

Reguły w regułach bezpieczeństwa magazynu oceniają każde zapytanie pod kątem jego potencjalnego wyniku i odrzucają żądanie, jeśli może ono zwrócić plik, do którego odczytania klient nie ma uprawnień. Żądania dostępu muszą być zgodne z ograniczeniami określonymi w Twoich zasadach.

Następne kroki

Możesz pogłębić swoją wiedzę na temat reguł bezpieczeństwa Firebase dla Cloud Storage:

Możesz zapoznać się z przypadkami użycia reguł zabezpieczeń Firebase specyficznych dla Google Cloud Storage: