Firebase Security Rules zapewniają kontrolę dostępu i weryfikację danych w formacie, który obsługuje o różnych poziomach złożoności. Tworzenie systemów dostępu opartych na użytkownikach i rolach które pozwalają utrzymać aby dane były bezpieczne, użyj aplikacji 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 zapewnia, że:
jako zmiennej, którą możesz wykorzystać w regułach. Zmienna auth
zawiera następujące informacje:
uid
: unikalny identyfikator użytkownika przypisany do użytkownika, który wysłał prośbę.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 potwierdzają swoje 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 UID Firebase użytkownika. Jest to unikalna wartość w obrębie projektu. |
firebase.identities |
Słownik wszystkich tożsamości powiązanych z kontem tego użytkownika. Słownik może zawierać te klucze: email , phone , google.com , facebook.com , github.com , twitter.com . Wartościami słownika są 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, który został użyty do uzyskania tego tokena. Może to być jeden z tych ciągów: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com . |
firebase.tenant |
Identyfikator najemcy powiązany z kontem, jeśli istnieje. np. tenant2-m6tyz |
Jeśli chcesz dodać niestandardowe atrybuty uwierzytelniania, auth.token
zawiera też wszelkie roszczenia niestandardowe
określonych przez Ciebie.
Gdy użytkownik proszący o dostęp nie jest zalogowany, zmienna auth
ma wartość null
.
Możesz użyć tej opcji w regułach, jeśli na przykład chcesz ograniczyć odczyt
dostęp do uwierzytelnionych użytkowników – auth != null
. Ogólnie zalecamy jednak,
dalsze ograniczenie uprawnień do zapisu.
Więcej informacji o zmiennej auth
znajdziesz w dokumentacji
dokumentacja dla
Cloud Firestore,
Realtime Database oraz
Cloud Storage.
Wykorzystywanie informacji o użytkownikach w regułach
W praktyce używanie uwierzytelnionych informacji w regułach sprawia, że reguły wydajniejszy i bardziej elastyczny. Możesz kontrolować dostęp do danych na podstawie użytkowników tożsamości.
Określ w regułach, jak informacje w zmiennej auth
mają być
informacje o użytkowniku żądającego – dopasowuje informacje o użytkowniku powiązane z
żądane dane.
Na przykład aplikacja może zapewniać, że użytkownicy mogą tylko odczytywać i zapisywać
do własnych danych. W tym scenariuszu potrzebujesz dopasowania
Zmienna auth.uid
i identyfikator użytkownika na żą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
do zdefiniowania przypisanych pól niestandardowych
użytkownikom aplikacji.
Załóżmy, że chcesz utworzyć administratora, rola, która umożliwia dostęp do zapisu na określonych ścieżkach. przypiszesz ten atrybut użytkownikom, a następnie wykorzystać go w regułach przyznających dostęp na ścieżkach.
W usłudze Cloud Firestore możesz dodać pole niestandardowe do pól dokumentów i pobierania za pomocą odczytu umieszczonego w Twoich regułach. Zatem, administrator, będzie 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;
}
}
Roszczenia niestandardowe są dostępne w Rules po utworzeniu roszczeń niestandardowych w Authentication. 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 użycia podstawowych funkcji Rules z wykorzystaniem narzędzia Authentication znajdziesz tutaj: Podstawowe reguły zabezpieczeń