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

Użyj warunków w regułach zabezpieczeń pamięci masowej Firebase

Ten przewodnik opiera się na podstawowej składni przewodnika językowego reguł zabezpieczeń Firebase, aby pokazać, jak dodawać warunki do reguł zabezpieczeń Firebase dla Cloud Storage.

Podstawowym elementem składowym reguł bezpieczeństwa magazynu jest warunek . Warunek to wyrażenie boolowskie, które określa, czy dana operacja powinna być dozwolona, ​​czy zabroniona. W przypadku podstawowych reguł używanie true i false literałów jako warunków działa doskonale. Jednak język Firebase Security Rules for Cloud Storage umożliwia pisanie bardziej złożonych warunków, które mogą:

  • Sprawdź uwierzytelnianie użytkownika
  • Sprawdź poprawność danych przychodzących

Poświadczenie

Reguły zabezpieczeń Firebase dla Cloud Storage integrują się z uwierzytelnianiem Firebase, aby zapewnić zaawansowane uwierzytelnianie użytkowników w Google Cloud Storage. Pozwala to na szczegółową kontrolę dostępu na podstawie oświadczeń tokenu uwierzytelniania Firebase.

Gdy uwierzytelniony użytkownik wykonuje żądanie w Google Cloud Storage, zmienna request.auth jest wypełniana uid użytkownika ( request.auth.uid ), a także żądaniami tokenów JWT uwierzytelniania Firebase ( request.auth.token ).

Ponadto w przypadku korzystania z uwierzytelniania niestandardowego dodatkowe oświadczenia są wyświetlane w polu request.auth.token .

Gdy nieuwierzytelniony użytkownik wykonuje żądanie, zmienna request.auth ma null .

Korzystając z tych danych, istnieje kilka typowych sposobów korzystania z uwierzytelniania w celu zabezpieczenia plików:

  • Publiczne: ignoruj request.auth
  • Uwierzytelnione prywatne: sprawdź, czy request.auth nie ma null
  • Prywatny użytkownik: sprawdź, czy request.auth.uid jest równy uid ścieżki
  • Grupa prywatna: sprawdź oświadczenia tokena niestandardowego, aby pasowały do ​​wybranego roszczenia, lub przeczytaj metadane pliku, aby zobaczyć, czy istnieje pole metadanych

Publiczny

Każda reguła, która nie uwzględnia kontekstu request.auth może zostać uznana za regułę public , ponieważ nie uwzględnia kontekstu uwierzytelniania użytkownika. Reguły te mogą być przydatne do ujawniania danych publicznych, takich jak zasoby gier, pliki dźwiękowe lub inna zawartość statyczna.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

Uwierzytelnione prywatne

W niektórych przypadkach możesz chcieć, aby dane były widoczne dla wszystkich uwierzytelnionych użytkowników aplikacji, ale nie dla nieuwierzytelnionych użytkowników. Ponieważ zmienna request.auth ma null dla wszystkich nieuwierzytelnionych użytkowników, wszystko co musisz zrobić, to sprawdzić, czy zmienna request.auth istnieje, aby wymagać uwierzytelnienia:

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

Prywatny użytkownik

Zdecydowanie najczęstszym przypadkiem użycia request.auth będzie przyznanie indywidualnym użytkownikom szczegółowych uprawnień do ich plików: od przesyłania zdjęć profilowych po czytanie prywatnych dokumentów.

Ponieważ pliki w Google Cloud Storage mają pełną „ścieżkę” do pliku, do utworzenia pliku kontrolowanego przez użytkownika wystarczy fragment unikatowej informacji identyfikującej użytkownika w prefiksie nazwy pliku (np. Identyfikator uid użytkownika), którą można zaznaczone, gdy reguła jest oceniana:

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

Grupa prywatna

Innym równie powszechnym przypadkiem użycia będzie zezwolenie na uprawnienia grupowe do obiektu, na przykład zezwolenie kilku członkom zespołu na współpracę nad udostępnionym dokumentem. Można to zrobić na kilka sposobów:

  • Wydrukuj niestandardowy token uwierzytelniania Firebase, który zawiera dodatkowe informacje o członku grupy (takie jak identyfikator grupy)
  • Dołącz informacje o grupie (takie jak identyfikator grupy lub lista autoryzowanych uid ) w metadanych pliku

Po zapisaniu tych danych w metadanych tokena lub pliku można się do nich odwoływać z poziomu reguły:

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

Poproś o ocenę

Przesłane, pobrane pliki, zmiany metadanych i usunięcia są oceniane na podstawie request wysłanego do Google Cloud Storage. Oprócz unikalnego identyfikatora użytkownika i ładunku uwierzytelniania Firebase w obiekcie request.auth jak opisano powyżej, zmienna request zawiera ścieżkę do pliku, w którym żądanie jest wykonywane, czas odebrania żądania oraz nową wartość resource jeśli prośba jest zapisem. Uwzględniane są również nagłówki HTTP i stan uwierzytelniania.

Obiekt request zawiera również unikatowy identyfikator użytkownika i ładunek uwierzytelniania Firebase w obiekcie request.auth , co zostanie wyjaśnione dokładniej w sekcji Bezpieczeństwo oparte na użytkownikach w dokumentacji.

Pełna lista właściwości w obiekcie request jest dostępna poniżej:

własność Rodzaj Opis
auth map <string, string> Gdy użytkownik jest zalogowany, podaje uid , unikalny identyfikator użytkownika oraz token , czyli mapę oświadczeń token JWT uwierzytelniania Firebase. W przeciwnym razie będzie null .
params map <string, string> Mapa zawierająca parametry zapytania żądania.
path ścieżka path reprezentująca ścieżkę, na której jest wykonywane żądanie.
resource map <string, string> Nowa wartość zasobu, obecna tylko w żądaniach write .
time znak czasu Sygnatura czasowa reprezentująca czas serwera, w którym żądanie jest oceniane.

Ocena zasobów

Podczas oceny reguł możesz także chcieć ocenić metadane przesyłanego, pobieranego, modyfikowanego lub usuwanego pliku. Pozwala to na tworzenie złożonych i potężnych reguł, które pozwalają na przesyłanie tylko plików z określonymi typami zawartości lub usuwanie tylko plików większych niż określony rozmiar.

Reguły bezpieczeństwa Firebase dla Cloud Storage zapewniają metadane plików w obiekcie resource , które zawierają pary klucz / wartość metadanych pojawiających się w obiekcie Google Cloud Storage. Te właściwości można sprawdzić w żądaniach read lub write aby zapewnić integralność danych.

W przypadku żądań write (takich jak przesyłanie, aktualizowanie i usuwanie metadanych), oprócz obiektu resource , który zawiera metadane pliku dla pliku, który obecnie istnieje na ścieżce żądania, masz również możliwość korzystania z obiektu request.resource , który zawiera podzbiór metadanych pliku do zapisania, jeśli zapis jest dozwolony. Możesz użyć tych dwóch wartości, aby zapewnić integralność danych lub wymusić ograniczenia aplikacji, takie jak typ lub rozmiar pliku.

Pełna lista właściwości w obiekcie resource jest dostępna poniżej:

własność Rodzaj Opis
name strunowy Pełna nazwa obiektu
bucket strunowy Nazwa zasobnika, w którym znajduje się ten obiekt.
generation int Generowanie obiektu GCS tego obiektu.
metageneration int Metageneracja obiektu GCS tego obiektu.
size int Rozmiar obiektu w bajtach.
timeCreated znak czasu Sygnatura czasowa reprezentująca czas utworzenia obiektu.
updated znak czasu Sygnatura czasowa reprezentująca czas ostatniej aktualizacji obiektu.
md5Hash strunowy Skrót MD5 obiektu.
crc32c strunowy Skrót crc32c obiektu.
etag strunowy Etag powiązany z tym obiektem.
contentDisposition strunowy Dyspozycja treści skojarzona z tym obiektem.
contentEncoding strunowy Kodowanie treści skojarzone z tym obiektem.
contentLanguage strunowy Język treści powiązany z tym obiektem.
contentType strunowy Typ zawartości powiązany z tym obiektem.
metadata map <string, string> Pary klucz / wartość dodatkowych niestandardowych metadanych określonych przez programistę.

request.resource zawiera wszystkie te elementy z wyjątkiem generation , metageneration , etag , timeCreated i updated .

Sprawdź poprawność danych

Reguły bezpieczeństwa Firebase dla Cloud Storage mogą być również używane do sprawdzania poprawności danych, w tym sprawdzania poprawności nazwy i ścieżki pliku, a także właściwości metadanych pliku, takich jak contentType i size .

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Funkcje niestandardowe

Gdy Twoje Reguły Bezpieczeństwa Firebase stają się bardziej złożone, możesz chcieć zawinąć zestawy warunków w funkcje, których możesz ponownie użyć w swoim zestawie reguł. Reguły bezpieczeństwa obsługują funkcje niestandardowe. Składnia funkcji niestandardowych przypomina trochę JavaScript, ale funkcje reguł zabezpieczeń Firebase są napisane w języku specyficznym dla domeny, który ma kilka ważnych ograniczeń:

  • Funkcje mogą zawierać tylko jedną instrukcję return . Nie mogą zawierać żadnej dodatkowej logiki. Na przykład nie mogą wykonywać pętli ani wywoływać usług zewnętrznych.
  • Funkcje mogą automatycznie uzyskiwać dostęp do funkcji i zmiennych z zakresu, w którym zostały zdefiniowane. Na przykład funkcja zdefiniowana w zakresie service firebase.storage ma dostęp do zmiennej resource , a tylko w przypadku Cloud Firestore do wbudowanych funkcji, takich jak get() i exists() .
  • Funkcje mogą wywoływać inne funkcje, ale nie mogą się powtarzać. Całkowita głębokość stosu wywołań jest ograniczona do 10.
  • W wersji rules2 funkcje mogą definiować zmienne za pomocą słowa kluczowego let . Funkcje mogą mieć dowolną liczbę powiązań let, ale muszą kończyć się instrukcją return.

Funkcja jest definiowana za pomocą słowa kluczowego function i przyjmuje zero lub więcej argumentów. Na przykład możesz chcieć połączyć dwa typy warunków użytych w powyższych przykładach w jedną funkcję:

service firebase.storage {
  match /b/{bucket}/o {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }
    match /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

Korzystanie z funkcji w regułach zabezpieczeń Firebase ułatwia ich konserwację wraz ze wzrostem złożoności reguł.

Następne kroki

Po omówieniu warunków masz bardziej zaawansowane zrozumienie Reguł i jesteś gotowy do:

Dowiedz się, jak obsługiwać podstawowe przypadki użycia i poznaj przepływ pracy przy tworzeniu, testowaniu i wdrażaniu reguł: