Reguły bezpieczeństwa Firebase pozwalają kontrolować dostęp do przechowywanych danych. Elastyczna składnia reguł oznacza, że możesz tworzyć reguły pasujące do wszystkiego, od wszystkich zapisów do całej bazy danych po operacje na określonym dokumencie.
W tym przewodniku opisano niektóre z bardziej podstawowych przypadków użycia, które warto wdrożyć podczas konfigurowania aplikacji i zabezpieczania danych. Zanim jednak zaczniesz pisać reguły, możesz chcieć dowiedzieć się więcej o języku , w którym są napisane, i o ich zachowaniu .
Aby uzyskać dostęp do reguł i je zaktualizować, wykonaj czynności opisane w artykule Zarządzanie i wdrażanie reguł zabezpieczeń Firebase .
Reguły domyślne: tryb zablokowany
Tworząc instancję bazy danych lub magazynu w konsoli Firebase, wybierasz, czy reguły bezpieczeństwa Firebase ograniczają dostęp do Twoich danych ( tryb zablokowany ), czy zezwalają na dostęp każdemu ( tryb testowy ). W Cloud Firestore i Realtime Database domyślne reguły trybu zablokowanego odmawiają dostępu wszystkim użytkownikom. W Cloud Storage dostęp do zasobników pamięci mają tylko uwierzytelnieni użytkownicy.
Chmura Firestore
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Baza danych czasu rzeczywistego
{
"rules": {
".read": false,
".write": false
}
}
Magazyn w chmurze
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Zasady rozwoju i ochrony środowiska
Podczas pracy nad aplikacją możesz chcieć stosunkowo otwartego i nieskrępowanego dostępu do swoich danych. Pamiętaj tylko o zaktualizowaniu reguł przed wdrożeniem aplikacji w środowisku produkcyjnym. Pamiętaj też, że jeśli wdrożysz aplikację, będzie ona publicznie dostępna — nawet jeśli jej nie uruchomiłeś .
Pamiętaj, że Firebase umożliwia klientom bezpośredni dostęp do Twoich danych, a Reguły Bezpieczeństwa Firebase są jedynym zabezpieczeniem blokującym dostęp złośliwym użytkownikom. Definiowanie reguł oddzielnie od logiki produktu ma wiele zalet: klienci nie są odpowiedzialni za egzekwowanie bezpieczeństwa, błędne implementacje nie naruszą Twoich danych, a co najważniejsze, nie musisz polegać na serwerze pośredniczącym w celu ochrony danych przed światem.
Wszyscy uwierzytelnieni użytkownicy
Chociaż nie zalecamy udostępniania danych każdemu zalogowanemu użytkownikowi, podczas tworzenia aplikacji przydatne może być ustawienie dostępu dla dowolnego uwierzytelnionego użytkownika.
Chmura Firestore
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
Baza danych czasu rzeczywistego
{
"rules": {
".read": "auth.uid !== null",
".write": "auth.uid !== null"
}
}
Magazyn w chmurze
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Reguły gotowe do produkcji
Przygotowując się do wdrożenia aplikacji, upewnij się, że Twoje dane są chronione, a użytkownicy mają odpowiedni dostęp. Wykorzystaj uwierzytelnianie , aby skonfigurować dostęp oparty na użytkownikach i czytać bezpośrednio z bazy danych, aby skonfigurować dostęp oparty na danych.
Rozważ napisanie reguł podczas porządkowania danych, ponieważ sposób ich skonfigurowania wpływa na sposób ograniczania dostępu do danych różnymi ścieżkami.
Dostęp tylko dla właściciela treści
Reguły te ograniczają dostęp wyłącznie do uwierzytelnionego właściciela treści. Dane mogą być odczytywane i zapisywane tylko przez jednego użytkownika, a ścieżka danych zawiera identyfikator użytkownika.
Kiedy ta reguła działa: Ta reguła działa dobrze, jeśli dane są izolowane przez użytkownika — jeśli jedynym użytkownikiem, który musi uzyskać dostęp do danych, jest ten sam użytkownik, który je utworzył.
Kiedy ta reguła nie działa: Ten zestaw reguł nie działa, gdy wielu użytkowników musi zapisać lub odczytać te same dane — użytkownicy zastąpią dane lub nie będą mogli uzyskać dostępu do utworzonych przez siebie danych.
Aby skonfigurować tę regułę: Utwórz regułę potwierdzającą, że użytkownik żądający dostępu do odczytu lub zapisu danych jest właścicielem tych danych.
Chmura Firestore
service cloud.firestore {
match /databases/{database}/documents {
// Allow only authenticated content owners access
match /some_collection/{userId}/{documents=**} {
allow read, write: if request.auth != null && request.auth.uid == userId
}
}
}
Baza danych czasu rzeczywistego
{
"rules": {
"some_path": {
"$uid": {
// Allow only authenticated content owners access to their data
".read": "auth !== null && auth.uid === $uid",
".write": "auth !== null && auth.uid === $uid"
}
}
}
}
Magazyn w chmurze
// Grants a user access to a node matching their user ID
service firebase.storage {
match /b/{bucket}/o {
// Files look like: "user/<UID>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}
Mieszany dostęp publiczny i prywatny
Ta reguła pozwala każdemu odczytać zestaw danych, ale ogranicza możliwość tworzenia lub modyfikowania danych w danej ścieżce tylko do uwierzytelnionego właściciela treści.
Kiedy ta reguła działa: Ta reguła działa dobrze w przypadku aplikacji, które wymagają elementów czytelnych publicznie, ale muszą ograniczyć dostęp do edycji do właścicieli tych elementów. Na przykład aplikacja do czatowania lub blog.
Kiedy ta reguła nie działa: Podobnie jak reguła „Tylko właściciel treści”, ten zestaw reguł nie działa, gdy wielu użytkowników musi edytować te same dane. Użytkownicy ostatecznie nadpiszą swoje dane.
Aby skonfigurować tę regułę: Utwórz regułę, która umożliwi dostęp do odczytu wszystkim użytkownikom (lub wszystkim uwierzytelnionym użytkownikom) i potwierdzi, że użytkownik zapisujący dane jest właścicielem.
Chmura Firestore
service cloud.firestore {
match /databases/{database}/documents {
// Allow public read access, but only content owners can write
match /some_collection/{document} {
allow read: if true
allow create: if request.auth.uid == request.resource.data.author_uid;
allow update, delete: if request.auth.uid == resource.data.author_uid;
}
}
}
Baza danych czasu rzeczywistego
{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data
"rules": {
"some_path": {
"$uid": {
".read": true,
// or ".read": "auth.uid !== null" for only authenticated users
".write": "auth.uid === $uid"
}
}
}
}
Magazyn w chmurze
service firebase.storage {
match /b/{bucket}/o {
// Files look like: "user/<UID>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read;
allow write: if request.auth.uid == userId;
}
}
}
Dostęp oparty na atrybutach i rolach
Aby te reguły zadziałały, musisz zdefiniować i przypisać atrybuty użytkownikom w swoich danych. Reguły bezpieczeństwa Firebase sprawdzają żądanie względem danych z bazy danych lub metadanych pliku, aby potwierdzić lub odmówić dostępu.
Kiedy ta reguła działa: Jeśli przypisujesz rolę użytkownikom, ta reguła ułatwia ograniczenie dostępu na podstawie ról lub określonych grup użytkowników. Na przykład, jeśli przechowujesz oceny, możesz przypisać różne poziomy dostępu do grupy „uczniowie” (tylko czytanie ich treści), grupy „nauczyciele” (czytanie i pisanie przedmiotów) oraz grupy „dyrektorzy” (czytanie cała zawartość).
Gdy ta reguła nie działa: w bazach danych czasu rzeczywistego i magazynie w chmurze Twoje reguły nie mogą wykorzystywać metody get()
dostępnej w regułach Cloud Firestore. W związku z tym musisz zorganizować metadane bazy danych lub pliku tak, aby odzwierciedlały atrybuty używane w regułach.
Aby skonfigurować tę regułę: W Cloud Firestore dodaj pole w dokumentach użytkowników, które możesz przeczytać, a następnie ustrukturyzuj regułę tak, aby odczytywała to pole i warunkowo udzielała dostępu. W bazie danych czasu rzeczywistego utwórz ścieżkę danych, która definiuje użytkowników aplikacji i przyznaje im rolę w węźle podrzędnym.
Możesz także skonfigurować niestandardowe oświadczenia w obszarze Uwierzytelnianie , a następnie pobrać te informacje ze zmiennej auth.token
w dowolnych regułach bezpieczeństwa Firebase.
Atrybuty i role zdefiniowane przez dane
Te reguły działają tylko w Cloud Firestore i Realtime Database.
Chmura Firestore
Pamiętaj, że za każdym razem, gdy Twoje reguły obejmują odczyt, tak jak poniższe reguły, naliczana jest opłata za operację odczytu w Cloud Firestore.
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, Check a boolean `admin` attribute
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
}
}
}
Baza danych czasu rzeczywistego
{
"rules": {
"some_path": {
"${subpath}": {
//
".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
".read": true
}
}
}
}
Niestandardowe atrybuty i role roszczeń
Aby wdrożyć te reguły, skonfiguruj niestandardowe oświadczenia w uwierzytelnianiu Firebase, a następnie wykorzystaj oświadczenia w swoich regułach.
Chmura Firestore
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, check for an admin claim
allow write: if request.auth.token.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if request.auth.token.reader == "true";
allow write: if request.auth.token.writer == "true";
}
}
}
Baza danych czasu rzeczywistego
{
"rules": {
"some_path": {
"$uid": {
// Create a custom claim for each role or group
// you want to leverage
".write": "auth.uid !== null && auth.token.writer === true",
".read": "auth.uid !== null && auth.token.reader === true"
}
}
}
}
Magazyn w chmurze
service firebase.storage {
// 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;
}
}
Atrybuty najmu
Aby zaimplementować te reguły, skonfiguruj wielodostępność w Google Cloud Identity Platform (GCIP), a następnie wykorzystaj dzierżawcę w swoich regułach. Poniższe przykłady umożliwiają zapisy od użytkownika w określonej dzierżawie, np. tenant2-m6tyz
Chmura Firestore
service cloud.firestore {
match /databases/{database}/documents {
// For tenant-based access control, check for a tenantID
allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
allow read: true;
}
}
Baza danych czasu rzeczywistego
{
"rules": {
"some_path": {
"$uid": {
// Only allow reads and writes if user belongs to a specific tenant
".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
".read": "auth.uid !== null
}
}
}
}
Magazyn w chmurze
service firebase.storage {
// Only allow reads and writes if user belongs to a specific tenant
match /files/{tenantId}/{fileName} {
allow read: if request.auth != null;
allow write: if request.auth.token.firebase.tenant == tenantId;
}
}