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

Firebase Security Rules dla Cloud Storage umożliwiają kontrolowanie dostępu do obiektów przechowywanych w zasobnikach Cloud Storage. Elastyczna składnia reguł pozwala tworzyć reguły kontrolujące dowolną operację – od wszystkich zapisów w zasobniku Cloud Storage po operacje na określonym pliku.

Ten przewodnik opisuje podstawową składnię i strukturę Cloud Storage Security Rules do tworzenia kompletnych zestawów reguł.

Deklaracja usługi i bazy danych

Firebase Security Rules dla Cloud Storage zawsze zaczynają się od tej deklaracji:

service firebase.storage {
    // ...
}

Deklaracja service firebase.storage ogranicza zakres reguł do Cloud Storage, co zapobiega konfliktom między Cloud Storage Security Rules a regułami dotyczącymi innych usług, takich jak Cloud Firestore.

Podstawowe reguły odczytu i zapisu

Podstawowe reguły składają się z instrukcji match identyfikującej Cloud Storage zasobniki, instrukcji match określającej nazwę pliku oraz wyrażenia allow określającego kiedy dozwolony jest odczyt określonych danych. Wyrażenia allow określają metody dostępu (np. odczyt, zapis) oraz warunki, na podstawie których dostęp jest dozwolony lub zabroniony.

W domyślnym zestawie reguł pierwsza instrukcja match używa wyrażenia z symbolem wieloznacznym {bucket}, aby wskazać, że reguły mają zastosowanie do wszystkich zasobników w projekcie. Więcej informacji o dopasowywaniu za pomocą symboli wieloznacznych znajdziesz 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 match wskazują pliki. Instrukcja match może wskazywać konkretny plik, np. match /images/profilePhoto.png.

Symbole wieloznaczne w instrukcji match

Oprócz wskazywania pojedynczego pliku Security Rules mogą używać symboli wieloznacznych aby wskazywać dowolny plik, którego nazwa zaczyna się od danego ciągu znaków, w tym ukośników, np. match /images/{imageId}.

W powyższym przykładzie instrukcja match używa składni symbolu wieloznacznego {imageId}. Oznacza to, że reguła ma zastosowanie do każdego pliku, którego nazwa zaczyna się od /images/, np. /images/profilePhoto.png lub /images/croppedProfilePhoto.png. Gdy wyrażenia allow w instrukcji match są oceniane, zmienna imageId jest zastępowana nazwą pliku graficznego, np. profilePhoto.png lub croppedProfilePhoto.png.

Do zmiennej z symbolem wieloznacznym można odwoływać się w instrukcji match, aby autoryzować nazwę pliku lub ścieżkę:

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

Dane hierarchiczne

Jak już wspomnieliśmy, w Cloud Storage zasobniku nie ma struktury hierarchicznej. Stosując jednak konwencję nazewnictwa plików, która często obejmuje ukośniki w nazwach plików, możemy naśladować strukturę przypominającą zagnieżdżoną serię katalogów i podkatalogów. Ważne jest, aby zrozumieć jak Firebase Security Rules współdziałają z tymi nazwami plików.

Rozważmy sytuację, w której mamy zestaw plików, których nazwy zaczynają się od /images/. Firebase Security Rules mają zastosowanie tylko do pasującej nazwy pliku, więc kontrola dostępu zdefiniowana dla /images/ nie ma zastosowania do /mp3s/. Zamiast tego utwórz 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>;
    }
  }
}

Podczas zagnieżdżania instrukcji match ścieżka wewnętrznej instrukcji match jest zawsze dołączana do ścieżki zewnętrznej instrukcji match. Dlatego te 2 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/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

Rekurencyjne symbole wieloznaczne w instrukcji match

Oprócz symboli wieloznacznych, które pasują do ciągów znaków na końcu nazwy pliku i zwracają je, można zadeklarować symbol wieloznaczny obejmujący wiele segmentów , aby uzyskać bardziej złożone dopasowywanie. W tym celu dodaj =** do nazwy symbolu wieloznacznego, np. {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 kilka reguł, wynikiem jest OR wyniku oceny wszystkich reguł. Oznacza to, że jeśli jakakolwiek reguła pasująca do pliku zwraca wartość true, wynikiem jest true.

W powyższych regułach plik „images/profilePhoto.png” można odczytać, jeśli wartość condition lub other_condition jest równa prawda, natomiast plik „images/users/user:12345/profilePhoto.png” podlega tylko wynikowi other_condition.

Cloud Storage Security Rules nie są kaskadowe, a reguły są oceniane tylko wtedy, gdy ścieżka żądania pasuje do ścieżki z określonymi regułami.

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

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 szczegółowe

W niektórych sytuacjach warto podzielić operacje read i write na bardziej szczegółowe operacje. Na przykład aplikacja może wymagać stosowania innych warunków 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 file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Security 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 file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

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

Nakładające się instrukcje match

Nazwa pliku może pasować do więcej niż 1 instrukcji match. Jeśli do żądania pasuje kilka wyrażeń allow, dostęp jest dozwolony, jeśli którykolwiek z warunków jest równy true:

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

W powyższym przykładzie wszystkie odczyty i zapisy plików, których nazwa zaczyna się od /images/, są dozwolone, ponieważ druga reguła jest zawsze równa true, nawet jeśli pierwsza reguła jest równa false.

Reguły nie są filtrami

Po zabezpieczeniu danych i rozpoczęciu wykonywania operacji na plikach pamiętaj, że reguły bezpieczeństwa nie są filtrami. Nie możesz wykonywać operacji na zbiorze plików pasujących do wzorca nazw plików i oczekiwać, że Cloud Storage będzie uzyskiwać dostęp tylko do plików, do których bieżący klient ma uprawnienia.

Na przykład rozważ tę 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 to żądanie, ponieważ zestaw wyników może zawierać pliki, w których contentType nie jest równy image/png:

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

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

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

Dalsze kroki

Możesz pogłębić swoją wiedzę na temat Firebase Security Rules dla Cloud Storage:

• Poznaj następną ważną koncepcję języka reguł – dynamiczne warunki, które umożliwiają regułom sprawdzanie autoryzacji użytkownika, porównywanie istniejących i przychodzących danych, sprawdzanie poprawności przychodzących danych i inne działania.

• Zapoznaj się z typowymi przypadkami użycia dotyczącymi bezpieczeństwa oraz z Firebase Security Rules definicjami, które je rozwiązują.

Możesz zapoznać się z przypadkami użycia reguł bezpieczeństwa Firebase, które dotyczą Cloud Storage:Firebase Security Rules