Reguły bezpieczeństwa Firebase zapewniają kontrolę dostępu i weryfikację danych w formacie obsługującym wiele poziomów złożoności. Aby zbudować systemy dostępu oparte na użytkownikach i rolach, które chronią dane użytkowników, użyj uwierzytelniania Firebase z regułami zabezpieczeń Firebase.
Zidentyfikuj użytkowników
Uwierzytelnianie identyfikuje użytkowników żądających dostępu do Twoich danych i zapewnia te informacje jako zmienną, którą możesz wykorzystać w swoich regułach. Zmienna auth
zawiera następujące informacje:
-
uid
: unikalny identyfikator użytkownika przypisany do użytkownika żądającego. -
token
: mapa wartości zebranych przez uwierzytelnianie.
Zmienna auth.token
zawiera następujące wartości:
Pole | Opis |
---|---|
email | Adres e-mail powiązany z kontem, jeśli istnieje. |
email_verified | true jeśli użytkownik zweryfikował, że ma dostęp do adresu email - email . Niektórzy dostawcy automatycznie weryfikują posiadane adresy e-mail. |
phone_number | Numer telefonu powiązany z kontem, jeśli istnieje. |
name | Wyświetlana nazwa użytkownika, jeśli jest ustawiona. |
sub | UID użytkownika Firebase. Jest to wyjątkowe w ramach projektu. |
firebase.identities | Słownik wszystkich tożsamości powiązanych z kontem tego użytkownika. Klucze słownika mogą być dowolnymi z następujących: email , phone , google.com , facebook.com , github.com , twitter.com . Wartości słownika to tablice unikatowych identyfikatorów dla każdego dostawcy tożsamości skojarzonego 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żywany do uzyskiwania tego tokenu. Może być jednym z następujących ciągów: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com . |
Jeśli chcesz dodać niestandardowe atrybuty uwierzytelniania, zmienna auth.token
zawiera również wszelkie określone oświadczenia niestandardowe .
Gdy użytkownik żądający dostępu nie jest zalogowany, zmienna auth
ma null
. Możesz to wykorzystać w swoich regułach, jeśli na przykład chcesz ograniczyć dostęp do odczytu do uwierzytelnionych użytkowników - auth != null
. Jednak ogólnie zalecamy dalsze ograniczanie dostępu do zapisu.
Więcej informacji o zmiennej auth
można znaleźć w dokumentacji referencyjnej dotyczącej Cloud Firestore , Realtime Database i Cloud Storage .
Wykorzystaj informacje o użytkowniku w regułach
W praktyce użycie uwierzytelnionych informacji w regułach sprawia, że reguły są bardziej wydajne i elastyczne. Możesz kontrolować dostęp do danych na podstawie tożsamości użytkownika.
W swoich regułach określ, w jaki sposób informacje w zmiennej auth
- informacje o użytkowniku żądającego - są zgodne z informacjami o użytkowniku powiązanymi z żądanymi danymi.
Na przykład Twoja aplikacja może chcieć upewnić się, że użytkownicy mogą odczytywać i zapisywać tylko własne dane. W tym scenariuszu chciałbyś dopasować zmienną auth.uid
do identyfikatora 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;
}
}
}
Baza danych czasu rzeczywistego
{
"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"
}
}
}
}
Magazyn w chmurze
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;
}
}
Zdefiniuj niestandardowe informacje o użytkowniku
Możesz dodatkowo wykorzystać zmienną auth
do definiowania niestandardowych pól przypisanych do użytkowników Twojej aplikacji.
Na przykład załóżmy, że chcesz utworzyć rolę „administratora”, która umożliwia dostęp do zapisu na określonych ścieżkach. Możesz przypisać ten atrybut użytkownikom, a następnie wykorzystać go w regułach przyznających dostęp do ścieżek.
W Cloud Firestore możesz dodać niestandardowe pole do dokumentów użytkowników i pobrać wartość tego pola z osadzonym odczytem w regułach. Twoja reguła oparta na administratorze wyglądałaby więc tak, jak w następującym przykładzie:
Cloud Firestore
service cloud.firestore {
match "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;
}
}
W przypadku reguł w bazie danych czasu rzeczywistego i pamięci masowej w chmurze utwórz niestandardowe oświadczenia w uwierzytelnianiu. Następnie można odwoływać się do tych oświadczeń niestandardowych za pomocą zmiennej auth.token
.
Baza danych czasu rzeczywistego
{
"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"
}
}
}
Magazyn w chmurze
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;
}
}
Aby zobaczyć więcej przykładów podstawowych reguł wykorzystujących uwierzytelnianie, zobacz Podstawowe reguły zabezpieczeń .