Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Warunki użytkowania w regułach bezpieczeństwa Firebase Cloud Storage

Podręcznik ten opiera się na uczyć się składni rdzenia języka Rules Firebase zabezpieczeń przewodnika, aby pokazać, jak dodać do swoich warunków regulaminu Firebase bezpieczeństwa dla Cloud Storage.

Podstawowym budulcem Storage Cloud zasad bezpieczeństwa jest warunkiem. Warunek to wyrażenie logiczne, które określa, czy dana operacja powinna być dozwolona, ​​czy zabroniona. Do podstawowych zasad, używając true i false literały w warunkach działa perfekcyjnie dobrze. Ale język reguł zabezpieczeń Firebase dla Cloud Storage umożliwia tworzenie bardziej złożonych warunków, które mogą:

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

Uwierzytelnianie

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

Gdy użytkownik wykonuje uwierzytelniony wniosek przeciwko chmura składowania, request.auth Zmienna jest wypełniona użytkownika uid ( request.auth.uid ), jak również roszczeń Firebase Authentication JWT ( request.auth.token ).

Dodatkowo, przy użyciu uwierzytelniania niestandardowy dodatkowe żądania zostały pokryte w request.auth.token dziedzinie.

Jeśli niezidentyfikowany użytkownik wykonuje wniosek, request.auth zmienna jest null .

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

  • Publiczne: ignorować request.auth
  • Uwierzytelniona prywatnym: Sprawdź, request.auth nie jest null
  • Użytkownik prywatny: Sprawdź, request.auth.uid równa ścieżka uid
  • Grupa prywatna: sprawdź oświadczenia tokena niestandardowego, aby pasowały do ​​wybranego oświadczenia, lub przeczytaj metadane pliku, aby sprawdzić, czy istnieje pole metadanych

Publiczny

Każda reguła, że nie uważa request.auth kontekstu można uznać za public regułę, ponieważ nie bierze pod uwagę kontekst 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");
}

Uwierzytelniony prywatny

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

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

Prywatne użytkownika

Zdecydowanie najczęstsze zastosowanie dla request.auth będzie zapewnienie indywidualnych użytkowników z uprawnieniami ziarnistych na swoich plikach: ze zdjęć profilowych przesyłania do czytania dokumentów prywatnych.

Ponieważ pliki w chmurze mieć pełny „ścieżka” do pliku, wystarczy aby plik kontrolowany przez użytkownika jest dziełem niepowtarzalnym, informacje identyfikacji użytkownika w prefiksie nazwy pliku (na przykład użytkownika uid ), które mogą być sprawdzone 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 przyznanie uprawnień grupowych do obiektu, na przykład umożliwienie kilku członkom zespołu współpracy nad udostępnionym dokumentem. Można to zrobić na kilka sposobów:

  • Mięta uwierzytelniania Firebase niestandardowy znacznik , który zawiera dodatkowe informacje na temat członka grupy (taki jak ID grupy)
  • Zawierać informacje o grupach (takie jak identyfikator grupy lub listy autoryzowanego uid y) w metadanych pliku

Gdy dane te zostaną zapisane w tokenie lub metadanych 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ę

Załadowania, pliki do pobrania, zmiany metadanych i usuwa są oceniane przy użyciu request wysłanego do Cloud Storage. Oprócz unikalnego identyfikatora użytkownika oraz ładowności Authentication Firebase w request.auth obiektu opisanego powyżej, request zmienna zawiera ścieżkę do pliku, w którym wniosek jest wykonywana, czas po odebraniu żądania, a nowy resource wartości, jeżeli prośba jest zapisem. Uwzględniono również nagłówki HTTP i stan uwierzytelniania.

request obiekt zawiera również unikalny identyfikator użytkownika i ładowność Authentication Firebase w request.auth obiektu, co zostanie wyjaśnione w dalszej części User-Based Bezpieczeństwa odcinku docs.

Pełną listę właściwości w request obiektu dostępny jest poniżej:

Nieruchomość Rodzaj Opis
auth mapa<ciąg, ciąg> Gdy użytkownik jest zalogowany, zapewnia uid , użytkownik unikalny identyfikator, a token , mapa roszczeń Firebase Authentication JWT. W przeciwnym razie będzie null .
params mapa<ciąg, ciąg> Mapa zawierająca parametry zapytania żądania.
path ścieżka path reprezentujący ścieżkę żądanie jest wykonywane przy ul.
resource mapa<ciąg, ciąg> Nowa wartość zasobów, przedstawiamy tylko na write wniosków.
time znak czasu Znacznik czasu reprezentujący czas serwera, w którym żądanie jest oceniane.

Ocena zasobów

Podczas oceny reguł możesz również 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 treści lub usuwanie tylko plików większych niż określony rozmiar.

Firebase przepisów bezpieczeństwa dotyczących Cloud Storage zapewnia metadanych pliku w resource obiektu, który zawiera kluczowe pary wartości / metadanych powierzchniowe w obiekcie Cloud Storage. Właściwości te mogą być kontrolowane na read lub write wniosków w celu zapewnienia integralności danych.

Na write wniosków (takich jak przesyłanych, aktualizacji metadanych i usuwa), oprócz resource obiektu, który zawiera metadane pliku dla pliku, który obecnie istnieje w ścieżce żądania, masz również możliwość korzystania z request.resource obiektu który zawiera podzbiór metadanych pliku, które mają zostać zapisane, 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łną listę właściwości w resource obiektu dostępny jest poniżej:

Nieruchomość Rodzaj Opis
name strunowy Pełna nazwa obiektu
bucket strunowy Nazwa zasobnika, w którym znajduje się ten obiekt.
generation int Generacja obiekt Google Cloud Storage tego obiektu.
metageneration int Google Cloud Storage obiekt metageneration tego obiektu.
size int Rozmiar obiektu w bajtach.
timeCreated znak czasu Znacznik czasu reprezentujący czas utworzenia obiektu.
updated znak czasu Znacznik czasu reprezentujący czas ostatniej aktualizacji obiektu.
md5Hash strunowy Skrót MD5 obiektu.
crc32c strunowy Skrót crc32c obiektu.
etag strunowy etag skojarzony z tym obiektem.
contentDisposition strunowy Dyspozycja zawartości skojarzona z tym obiektem.
contentEncoding strunowy Kodowanie treści powiązane z tym obiektem.
contentLanguage strunowy Język treści powiązany z tym obiektem.
contentType strunowy Typ zawartości skojarzony z tym obiektem.
metadata mapa<ciąg, ciąg> Pary klucz/wartość dodatkowych metadanych niestandardowych określonych przez dewelopera.

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

Sprawdź poprawność danych

Firebase przepisów bezpieczeństwa dotyczących Cloud Storage może być również używany do sprawdzania poprawności danych, w tym sprawdzanie nazwę pliku i ścieżkę, jak również właściwości metadanych pliku, takie 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

W miarę jak Twoje reguły zabezpieczeń Firebase stają się coraz bardziej złożone, możesz chcieć otoczyć zestawy warunków funkcjami, które możesz ponownie wykorzystać 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 jeden return oświadczenie. 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 są zdefiniowane. Na przykład, funkcja zdefiniowana w service firebase.storage zakresie ma dostęp do resource zmiennej, a chmura FireStore tylko, wbudowane funkcje takie jak get() i exists() .
  • Funkcje mogą wywoływać inne funkcje, ale nie mogą rekursywnie. Całkowita głębokość stosu wywołań jest ograniczona do 10.
  • W wersji rules2 funkcje mogą definiować zmienne za pomocą let słowa kluczowego. Funkcje mogą mieć dowolną liczbę powiązań let, ale muszą kończyć się instrukcją return.

Funkcja jest zdefiniowana z function hasła i bierze zero lub więcej argumentów. Na przykład możesz chcieć połączyć dwa typy warunków użyte 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 sprawia, że ​​są one łatwiejsze w utrzymaniu w miarę wzrostu złożoności reguł.

Następne kroki

Po tym omówieniu warunków masz bardziej wyrafinowane zrozumienie reguł i jesteś gotowy do:

Dowiedz się, jak radzić sobie z podstawowymi przypadkami użycia i poznaj przepływ pracy podczas opracowywania, testowania i wdrażania reguł: