Catch up on everthing we announced at this year's Firebase Summit. Learn more

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

Reguły zabezpieczeń Firebase dla Cloud Storage umożliwiają kontrolowanie dostępu do obiektów przechowywanych w zasobnikach Cloud Storage. Elastyczna składnia reguł umożliwia tworzenie reguł do kontrolowania dowolnej operacji, od wszystkich zapisów do zasobnika Cloud Storage po operacje na określonym pliku.

Ten przewodnik opisuje podstawową składnię i strukturę reguł bezpieczeństwa Cloud Storage w celu tworzenia kompletnych zestawów reguł.

Deklaracja usług i bazy danych

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

service firebase.storage {
    // ...
}

service firebase.storage deklaracja celownicze zasady do Cloud Storage, zapobieganie konfliktom między chmurze zasad bezpieczeństwa bagażu i reguł dla innych produktów, takich jak chmura FireStore.

Podstawowe zasady odczytu/zapisu

Podstawowe reguły składają się z match oświadczenie identyfikujące wiadra chmurze, oświadczenie mecz określający nazwę pliku, a także allow wyrażenie szczegółowo podczas czytania podanych danych jest dozwolony. allow wyrażenia określa metody dostępu (np odczyt, zapis) jest zaangażowany, oraz warunki, w których dostęp jest albo dozwolona lub zabroniona.

W domyślnego zestawu reguł, pierwszy match oświadczenie używa {bucket} wieloznaczny wyraz wskazywać zasady mają zastosowanie do wszystkich wiader w projekcie. Omówimy ideę dopasowań wieloznacznych w następnej sekcji.

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

Wszystkie instrukcje dopasowania wskazują na pliki. Oświadczenie mecz może wskazywać na plik konkretnego, jak w match /images/profilePhoto.png .

Dopasuj symbole wieloznaczne

W additiont do wskazując na jednym pliku, Reguły można używać symboli wieloznacznych do punktu do dowolnego pliku z danego prefiksu ciągu w jego imieniu, w tym ukośniki, jak w match /images/{imageId} .

W powyższym przykładzie, oświadczenie mecz używa {imageId} składni wieloznaczny. Oznacza to, że zasada ta ma zastosowanie do każdego pliku z /images/ na początku jego nazwy, takie jak /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 .

Zmienna wieloznaczny można odwoływać się od wewnątrz match świadczenia nazwę pliku lub zezwolenia ś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 hierarchicznej struktury. 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ę zestawu plików z nazwami, że wszystko zaczęło się z /images/ macierzystych. Firebase Zasady bezpieczeństwa stosuje się jedynie przy dopasowanej nazwy pliku, więc kontrole dostępu zdefiniowane na /images/ macierzyste nie mają zastosowania do /mp3s/ macierzystych. Zamiast tego napisz wyraźne reguły, które pasują 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>;
    }
  }
}

Kiedy zagnieżdżanie match oświadczenia, ścieżka wewnętrznej match oświadczenie jest zawsze dołączona do ścieżki zewnętrznej match oświadczeniu. Poniższe dwa zestawy reguł są zatem 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/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

Rekurencyjne symbole wieloznaczne w dopasowaniu

Oprócz wieloznacznych pasujących i powrotu łańcuchy na końcu pliku, wielokrotność wieloznaczny segmentu może być uznana za bardziej złożonego dopasowania dodając =** nazwy maska, jak {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 kilka zasad dopasować plik, wynik jest OR wyniku wszystkich reguł oceny. Oznacza to, że jeżeli przepis plik pasuje do evalutes true , wynik jest true .

W powyższych zasad, plik „images / profilePhoto.png” można odczytać, czy też condition lub other_condition ocenić wartość true, gdy plik „images / users / user: 12345 / profilePhoto.png” jest tylko przedmiotem wyniku other_condition .

Reguły zabezpieczeń Cloud Storage nie działają kaskadowo, 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 rekurencyjne symbole wieloznaczne dopasowują jeden lub więcej elementów nazwy pliku, a nie zero lub więcej elementów. Zatem match /images/{filenamePrefixWildcard}/{imageFilename=**} pasuje do nazwy pliku jak /images/profilePics/profile.png, ale nie /images/badge.png. Zastosowanie /images/{imagePrefixorFilename=**} zamian.

Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu oświadczenia meczu.

Zalecamy korzystanie z wersji 2 ze względu na jej bardziej zaawansowane funkcje.

Wersja 2

W wersji 2 reguł zabezpieczeń Firebase rekurencyjne symbole wieloznaczne odpowiadają zero lub większej liczbie elementów ścieżki. W ten sposób /images/{filenamePrefixWildcard}/{imageFilename=**} odpowiada nazewnictwo /images/profilePics/profile.png i /images/badge.png.

Musisz zgłosić się do wersji 2 poprzez dodanie rules_version = '2'; u góry Twoich zasad bezpieczeństwa:

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

Możesz mieć co najwyżej jeden rekurencyjny symbol wieloznaczny na instrukcję dopasowania, ale w wersji 2 możesz umieścić ten symbol wieloznaczny 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 Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

Operacje granularne

W niektórych sytuacjach jest to przydatne do rozbicia read i write do operacji bardziej ziarnistych. Na przykład aplikacja może chcieć wymusić inne warunki podczas tworzenia pliku niż podczas usuwania pliku.

read operacja może być podzielona na get i list .

write reguła może zostać podzielony 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 updates to file metadata
      allow update: if <condition>;

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

Pokrywające się stwierdzenia dotyczące dopasowania

Jest to możliwe, nazwa pliku, aby dopasować więcej niż jeden match oświadczenie. W przypadku wielokrotnego allow wyrażenia dopasować żądanie, dostęp jest dozwolony, jeżeli 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 odczytuje i zapisuje pliki z ciągiem /images/ gdziekolwiek w nazwie pliku będzie dozwolone, ponieważ druga zasada jest zawsze true , choć pierwsza zasada jest zawsze false .

Reguły to nie filtry

Gdy zabezpieczysz swoje dane i zaczniesz wykonywać operacje na plikach, pamiętaj, że reguły bezpieczeństwa nie są filtrami. Nie możesz wykonywać operacji na zbiorze plików pasującym do wzorca nazwy pliku i oczekiwać, że Cloud Storage będzie mieć dostęp tylko do plików, do których bieżący klient ma uprawnienia dostępu.

Weźmy na przykład 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: Zasada ta odrzuca następujące żądania, ponieważ zestaw wyników może zawierać pliki gdzie contentType nie jest image/png :

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

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

Reguły w Cloud Storage Reguły bezpieczeństwa oceniają każde zapytanie pod kątem jego potencjalnego wyniku i kończy się niepowodzeniem, jeśli może zwrócić plik, do którego klient nie ma uprawnień do odczytu. Żądania dostępu muszą być zgodne z ograniczeniami określonymi przez Twoje reguły.

Następne kroki

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

  • Dowiedz się kolejną ważną koncepcję języka reguł, dynamicznych warunkach , które pozwalają reguły wyboru autoryzacji użytkownika, porównać istniejące i przychodzących danych, sprawdzania poprawności danych przychodzących i więcej.

  • Przeglądu typowych przypadków użycia bezpieczeństwa i definicje Firebase zasad bezpieczeństwa, że ich rozwiązania .

Możesz poznać przypadki użycia reguł zabezpieczeń Firebase specyficzne dla Cloud Storage: