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 chronią dane użytkowników, użyj 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 przekazuje te informacje jako zmienną, której możesz używać w regułach. Zmienna auth
zawiera te informacje:
uid
: wyjątkowy identyfikator użytkownika przypisany do użytkownika przesył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 istnieje). |
email_verified |
true , jeśli użytkownik potwierdził, że ma dostęp do adresu email . Niektórzy dostawcy automatycznie weryfikują należące do nich adresy e-mail. |
phone_number |
numer telefonu powiązany z kontem (jeśli istnieje); |
name |
Wyświetlana nazwa użytkownika (jeśli została ustawiona). |
sub |
Identyfikator Firebase użytkownika. Musi być unikalny 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 tych wartości: email , phone , google.com , facebook.com , github.com , twitter.com . Wartości w słowniku to tablice unikalnych identyfikatorów dla każdego dostawcy tożsamości powiązanego z kontem. Na przykład auth.token.firebase.identities["google.com"][0] zawiera pierwsze identyfikator użytkownika Google powiązany z kontem. |
firebase.sign_in_provider |
Dostawca logowania użyty do uzyskania tego tokena. Może być dowolnym 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). Przykład: tenant2-m6tyz |
Jeśli chcesz dodać niestandardowe atrybuty uwierzytelniania, zmienna auth.token
zawiera też określone przez Ciebie oświadczenia niestandardowe.
Jeśli użytkownik, który prosi o dostęp, nie jest zalogowany, zmienna auth
ma wartość null
.
Możesz wykorzystać to w swoich regułach, jeśli na przykład chcesz ograniczyć dostęp do odczytu użytkownikom uwierzytelnionym (auth != null
). Ogólnie zalecamy jednak ograniczenie dostępu do zapisu.
Więcej informacji o zmiennej auth
znajdziesz w dokumentacji referencyjnej dotyczącej funkcji Cloud Firestore, Realtime Database i Cloud Storage.
Wykorzystanie informacji o użytkownikach w regułach
W praktyce używanie uwierzytelnionych informacji w regułach sprawia, że reguły stają się bardziej elastyczne i skuteczne. Możesz kontrolować dostęp do danych na podstawie tożsamości użytkownika.
W regułach określ, jak informacje w zmiennej auth
(informacje o użytkowniku zgłaszającego żądanie) pasują do informacji o użytkowniku powiązanych z żądanymi danymi.
Aplikacja może na przykład wymagać, aby użytkownicy mogli tylko odczytywać i zapisywać własne dane. W tym scenariuszu chcesz dopasować zmienną auth.uid
do identyfikatora użytkownika w wymaganych 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
Zmienną auth
możesz też wykorzystać do definiowania pól niestandardowych przypisanych użytkownikom aplikacji.
Załóżmy na przykład, że chcesz utworzyć rolę „administrator”, która umożliwia zapisywanie na określonych ścieżkach. Przypisz ten atrybut użytkownikom, a potem wykorzystaj 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ć jego wartość za pomocą wbudowanej funkcji odczytu w regułach. Twoja reguła administracyjna będzie więc wyglądać 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;
}
}
Do Rules możesz uzyskać dostęp w Authentication po utworz niestandardowe roszczenia. Następnie możesz odwoływać się do tych niestandardowych roszczeń 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 Rules wykorzystujących Authentication znajdziesz w artykule Podstawowe reguły zabezpieczeń.