Firebase Security Rules pozwala Ci kontrolować dostęp do przechowywanych danych. Elastyczne reguły składni oznacza, że możesz tworzyć reguły, które pasują do wszystkiego, od wszystkich zapisów po do operacji na konkretnym dokumencie.
W tym przewodniku opisaliśmy kilka podstawowych zastosowań, które warto wdrożyć podczas konfigurowania aplikacji i chronienia danych. Zanim jednak zacznij pisać reguły, zapoznaj się z języka, w którym są napisane, i ich zachowanie.
Aby uzyskać dostęp do reguł i je aktualizować, wykonaj czynności opisane w artykule Zarządzanie regułami Firebase Security Rules.
Reguły domyślne: tryb blokady
Gdy utworzysz bazę danych lub instancję pamięci masowej w konsoli Firebase, możesz wybrać, czy urządzenie Firebase Security Rules ma ograniczać dostęp do Twoich danych (tryb blokady) lub zezwolić na dostęp wszystkim użytkownikom (tryb testowy). Za Cloud Firestore i Realtime Database, domyślne reguły dla trybu blokady odmawiają dostępu wszystkim użytkownikom. W Cloud Storage tylko uwierzytelnieni użytkownicy mają dostęp do zasobników na dane.
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Realtime Database
{
"rules": {
".read": false,
".write": false
}
}
Cloud Storage
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Reguły środowiska programistycznego
Podczas pracy nad aplikacją mogą być potrzebne stosunkowo otwarte lub nieograniczone do swoich danych. Przed wdrożeniem aplikacji w wersji produkcyjnej zaktualizuj Rules. Pamiętaj też, że po wdrożeniu aplikacji jest publicznie dostępny, nawet jeśli nie został przez Ciebie uruchomiony.
Pamiętaj, że Firebase umożliwia klientom bezpośredni dostęp do Twoich danych. Firebase Security Rules to jedyne zabezpieczenie blokujące dostęp dla złośliwych użytkowników. Definiowanie ma szereg zalet: nie pozwala na zmianę odpowiedzialnym za egzekwowanie bezpieczeństwa, błędy wdrożenia nie zagrażają bezpieczeństwu. a co najważniejsze – nie musisz polegać na serwerze pośredniczącym, ochrony danych przed światem.
Wszyscy uwierzytelnieni użytkownicy
Nie zalecamy udostępniania danych wszystkim zalogowanym użytkownikom, ale podczas tworzenia aplikacji może być przydatne zezwalanie na dostęp wszystkim uwierzytelnionym użytkownikom.
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
Realtime Database
{
"rules": {
".read": "auth.uid !== null",
".write": "auth.uid !== null"
}
}
Cloud Storage
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Reguły gotowe do wykorzystania w środowisku produkcyjnym
Przygotowując się do wdrożenia aplikacji, upewnij się, że Twoje dane są chronione aby dostęp użytkowników był prawidłowo przyznany. Wykorzystanie Authentication, aby skonfigurować dostęp oparty na użytkownikach i bezpośrednie odczyty z Twojej bazy danych, aby skonfigurować dostęp na podstawie danych.
Rozważ pisanie reguł podczas tworzenia struktury danych, ponieważ sposób, w jaki skonfigurowane przez Ciebie reguły wpływają na sposób, w jaki ograniczasz dostęp do danych w różnych ścieżek konwersji.
Dostęp tylko dla właściciela treści
Te reguły ograniczają dostęp tylko do uwierzytelnionego właściciela treści. czy dane są czytelne i możliwe do zapisu tylko przez jednego użytkownika, a ścieżka danych zawiera identyfikator użytkownika.
Kiedy ta reguła działa: reguła działa dobrze, jeśli dane są odizolowane przez użytkownika – jeśli dostęp do danych potrzebuje tylko ten, który utworzył i skalowalnych danych.
Kiedy ta reguła nie działa: ten zestaw reguł nie działa, gdy wielu użytkowników musi zapisywać lub odczytywać te same dane – użytkownicy będą nadpisywać dane lub nie będą mieć do nich dostępu.
Aby skonfigurować tę regułę: utwórz regułę potwierdzającą, że użytkownik proszący o dostęp odczytują lub zapisu danych, to użytkownik jest ich właścicielem.
Cloud 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
}
}
}
Realtime Database
{
"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"
}
}
}
}
Cloud Storage
// 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;
}
}
}
Dostęp publiczny i prywatny nie jest ograniczony
Ta reguła umożliwia każdemu odczyt zbioru danych, ale ogranicza możliwość tworzyć lub modyfikować dane tylko na określonej ścieżce do uwierzytelnionego właściciela treści.
Kiedy działa ta reguła: ta reguła sprawdza się w przypadku aplikacji, które wymagają publicznie dostępnych elementów, ale muszą ograniczyć dostęp do edycji tych elementów do ich właścicieli. Może to być na przykład aplikacja do czatu lub blog.
Kiedy ta reguła nie działa: tak jak w przypadku reguły tylko właściciela treści, ten zestaw reguł nie działa, gdy wielu użytkowników chce edytować te same dane. Użytkownicy będą nadpisują sobie nawzajem dane.
Aby skonfigurować tę regułę: utwórz regułę, która umożliwia dostęp do odczytu wszystkim użytkownikom. (lub wszystkich uwierzytelnionych użytkowników) i potwierdza, że właścicielem danych jest użytkownik, który zapisuje dane.
Cloud 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;
}
}
}
Realtime Database
{
// 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"
}
}
}
}
Cloud Storage
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 ta reguła działała, musisz zdefiniować i przypisać atrybuty użytkownikom w i skalowalnych danych. Firebase Security Rules sprawdzają żądanie pod kątem danych z Twojej bazy danych lub metadanych pliku, aby potwierdzić lub odmówić dostępu.
Kiedy ta reguła działa: jeśli przypisujesz rolę użytkownikom, reguła ta sprawia, możesz łatwo ograniczyć dostęp na podstawie ról lub określonych grup użytkowników. Jeśli na przykład przechowujesz oceny, możesz przypisać różne poziomy dostępu do grupy „uczniowie” (tylko do odczytu), grupy „nauczyciele” (czytanie i zapisywanie w temacie) oraz grupy „dyrektorzy” (czytanie wszystkich treści).
Gdy ta reguła nie działa: w Realtime Database i Cloud Storage reguły
nie może użyć metody get(), którą mogą zastosować reguły Cloud Firestore.
Dlatego musisz utworzyć strukturę bazy danych lub pliku, aby odzwierciedlały one
atrybutów używanych w regułach.
Aby skonfigurować tę regułę: w Cloud Firestore uwzględnij pole w tagu użytkownika które można odczytać, a następnie utworzyć regułę i warunkowo przyznaj dostęp. Utwórz w usłudze Realtime Database ścieżkę danych, która definiuje użytkowników aplikacji i przypisuje im rolę w węźle podrzędnym.
Możesz też skonfigurować roszczenia niestandardowe w Authentication
oraz pobierać te informacje z
Zmienną auth.token w dowolnym elemencie Firebase Security Rules.
Atrybuty i role zdefiniowane przez dane
Te reguły działają tylko w Cloud Firestore i Realtime Database.
Cloud Firestore
Pamiętaj, że za każdym razem, gdy jakieś reguły zawierają odczyt, tak jak w przypadku poniższych reguł, płacisz 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"
}
}
}
Realtime Database
{
"rules": {
"some_path": {
"${subpath}": {
//
".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
".read": true
}
}
}
}
Atrybuty i role roszczeń niestandardowych
Aby zastosować te reguły, skonfiguruj roszczenia niestandardowe. w Firebase Authentication, a następnie wykorzystaj roszczenia w swoich regułach.
Cloud 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";
}
}
}
Realtime Database
{
"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"
}
}
}
}
Cloud Storage
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 najemcy
Aby wdrożyć te reguły, skonfiguruj środowisko wielu najemców w Google Cloud Identity Platform (GCIP).
a następnie wykorzystać najemcę w swoich regułach. W podanych niżej przykładach operacje zapisu są dozwolone dla użytkownika w konkretnym kliencie, np. tenant2-m6tyz
Cloud 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;
}
}
Realtime Database
{
"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
}
}
}
}
Cloud Storage
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;
}
}