Firebase Security Rules zapewniają kontrolę dostępu i weryfikację danych w formacie obsługującym wiele poziomów złożoności; Aby tworzyć systemy dostępu oparte na użytkownikach i rolach, które zapewniają bezpieczeństwo danych użytkowników, używaj Firebase Authentication z Firebase Security Rules.
Identyfikowanie użytkowników
Authentication identyfikuje użytkowników, którzy proszą o dostęp do Twoich danych, i udostępnia te informacje jako zmienną, której możesz używać w regułach. Zmienna auth
zawiera te informacje:
uid
: Unikalny identyfikator użytkownika przypisany do użytkownika wysyłającego żądanie.token
: mapa wartości zebranych przez Authentication.
Zmienna auth.token
zawiera te wartości:
Pole | Opis |
---|---|
email |
adres e-mail powiązany z kontem (jeśli jest dostępny); |
email_verified |
true , jeśli użytkownik potwierdził, że ma dostęp do adresu email . Niektórzy dostawcy automatycznie weryfikują adresy e-mail, których są właścicielami. |
phone_number |
numer telefonu powiązany z kontem (jeśli jest dostępny); |
name |
Wyświetlana nazwa użytkownika, jeśli została ustawiona. |
sub |
Identyfikator UID użytkownika w Firebase. Jest on unikalny w obrębie projektu. |
firebase.identities |
Słownik wszystkich tożsamości powiązanych z kontem tego użytkownika. Klucze słownika mogą być dowolne z tych wartości: email , phone , google.com , facebook.com , github.com , twitter.com . Wartości słownika to tablice unikalnych identyfikatorów każdego dostawcy tożsamości powiązanego z kontem. Na przykład auth.token.firebase.identities["google.com"][0] zawiera pierwszy identyfikator użytkownika Google powiązany z kontem. |
firebase.sign_in_provider |
Dostawca logowania użyty do uzyskania tego tokena. Może być jednym z tych ciągów: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com . |
firebase.tenant |
Identyfikator tenantId powiązany z kontem, jeśli występuje, np. tenant2-m6tyz . |
Jeśli chcesz dodać dostosowane atrybuty uwierzytelniania, zmienna auth.token
zawiera też wszystkie określone przez Ciebie niestandardowe roszczenia.
Gdy użytkownik proszący o dostęp nie jest zalogowany, zmienna auth
ma wartość null
.
Możesz wykorzystać to w regułach, jeśli na przykład chcesz ograniczyć dostęp do odczytu do uwierzytelnionych użytkowników – auth != null
. Zalecamy jednak ograniczenie dostępu do zapisu.
Więcej informacji o zmiennej auth
znajdziesz w dokumentacji referencyjnej dotyczącej Cloud Firestore, Realtime Database i Cloud Storage.
Wykorzystywanie informacji o użytkownikach w regułach
W praktyce używanie w regułach uwierzytelnionych informacji sprawia, że są one bardziej skuteczne i elastyczne. Możesz kontrolować dostęp do danych na podstawie tożsamości użytkownika.
W regułach określ, w jaki sposób informacje w zmiennej auth
– informacje o użytkowniku wysyłającym żądanie – pasują do informacji o użytkowniku powiązanych z danymi, o które wysłano żądanie.
Na przykład aplikacja może wymagać, aby użytkownicy mogli tylko odczytywać i zapisywać własne dane. W takiej sytuacji chcesz, aby zmienna auth.uid
była zgodna z identyfikatorem użytkownika w żądanych danych:
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents {
// Make sure the uid of the requesting user matches name of the user
// document. The wildcard expression {userId} makes the userId variable
// available in rules.
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}
Realtime Database
{
"rules": {
"users": {
"$userId": {
// grants write access to the owner of this user account
// whose uid must exactly match the key ($userId)
".write": "$userId === auth.uid"
}
}
}
}
Cloud Storage
service firebase.storage {
// Only a user can upload their file, but anyone can view it
match /users/{userId}/{fileName} {
allow read;
allow write: if request.auth != null && request.auth.uid == userId;
}
}
Definiowanie niestandardowych informacji o użytkowniku
Możesz dodatkowo wykorzystać zmienną auth
, aby zdefiniować pola niestandardowe przypisane do użytkowników aplikacji.
Załóżmy na przykład, że chcesz utworzyć rolę „administrator”, która umożliwia zapisywanie danych w określonych ścieżkach. Ten atrybut przypisujesz użytkownikom, a następnie wykorzystujesz go w regułach przyznających dostęp na ścieżkach.
W Cloud Firestore możesz dodać pole niestandardowe do dokumentów użytkowników i pobrać wartość tego pola za pomocą wbudowanego odczytu w regułach. Reguła oparta na uprawnieniach administracyjnych wyglądałaby tak:
Cloud Firestore
service cloud.firestore {
match /databases/{database}/documents/some_collection: {
// Remember that, in Cloud Firestore, reads embedded in your rules are billed operations
write: if request.auth != null && get(/databases/(database)/documents/users/$(request.auth.uid)).data.admin == true;
read: if request.auth != null;
}
}
Dostęp do roszczeń niestandardowych możesz uzyskać w Rules po utworzeniu roszczeń niestandardowych w Authentication. Możesz się do nich odwoływać za pomocą zmiennej auth.token
.
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/$sub_path": {
// Create a custom claim for the admin role
".write": "auth.uid !== null && auth.token.writer === true"
".read": "auth.uid !== null"
}
}
}
Cloud Storage
service firebase.storage {
// Create a custom claim for the admin role
match /files/{fileName} {
allow read: if request.auth.uid != null;
allow write: if request.auth.token.admin == true;
}
}
Więcej przykładów podstawowych reguł zabezpieczeń Rules wykorzystujących Authentication znajdziesz w artykule Podstawowe reguły zabezpieczeń.