Ta strona została przetłumaczona przez Cloud Translation API.

Korzystanie z warunków w regułach zabezpieczeń bazy danych czasu rzeczywistego

Ten przewodnik uzupełnia podstawowy język reguł zabezpieczeń Firebase. aby pokazać, jak dodać warunki do reguł zabezpieczeń Bazy danych czasu rzeczywistego Firebase.

Podstawowym elementem składowym reguł zabezpieczeń bazy danych czasu rzeczywistego jest warunek. O jest wyrażeniem logicznym określającym, czy określona operacja powinno być dozwolone lub zabronione. W przypadku podstawowych reguł używaj literałów true i false jako działa idealnie. Język reguł zabezpieczeń bazy danych czasu rzeczywistego sposobów pisania bardziej złożonych warunków, które mogą:

Sprawdzanie uwierzytelniania użytkowników
Ocena istniejących danych z danymi przesłanymi ostatnio
uzyskiwać dostęp do różnych części bazy danych i porównywać je;
Weryfikuj dane przychodzące
Używaj struktury zapytań przychodzących na potrzeby logiki zabezpieczeń

Używanie zmiennych $ do przechwytywania segmentów ścieżki

Możesz przechwytywać fragmenty ścieżki do odczytu lub zapisu, zadeklarując przechwytywać zmienne z prefiksem $. Służy ona jako symbol wieloznaczny, a zapisuje wartość tego klucza do wykorzystania w niej warunki reguł:

{
  "rules": {
    "rooms": {
      // this rule applies to any child of /rooms/, the key for each room id
      // is stored inside $room_id variable for reference
      "$room_id": {
        "topic": {
          // the room's topic can be changed if the room id has "public" in it
          ".write": "$room_id.contains('public')"
        }
      }
    }
  }
}

Dynamicznych zmiennych $ można też używać równolegle ze stałą ścieżką. nazw. W tym przykładzie używamy zmiennej $other do deklarowania regułę .validate, która zapewnia widget nie ma elementów potomnych innych niż title i color. Każdy zapis, który spowodowałby utworzenie dodatkowych elementów podrzędnych, kończy się niepowodzeniem.

{
  "rules": {
    "widget": {
      // a widget can have a title or color attribute
      "title": { ".validate": true },
      "color": { ".validate": true },

      // but no other child paths are allowed
      // in this case, $other means any key excluding "title" and "color"
      "$other": { ".validate": false }
    }
  }
}

Uwierzytelnianie

Jednym z najczęstszych wzorców reguł zabezpieczeń jest kontrola dostępu stan uwierzytelniania użytkownika. Na przykład aplikacja może zezwalać tylko na zalogowanych użytkowników na zapisywanie danych.

Jeśli Twoja aplikacja korzysta z uwierzytelniania Firebase, zmienna request.auth zawiera dane uwierzytelniające klienta, który żąda danych. Więcej informacji o request.auth znajdziesz w dokumentacji dokumentacji.

Uwierzytelnianie Firebase integruje się z Bazą danych czasu rzeczywistego Firebase, dzięki czemu możesz kontrolować dane. dostęp dla poszczególnych użytkowników przy użyciu warunków. Po uwierzytelnieniu użytkownika auth w regułach zabezpieczeń bazy danych czasu rzeczywistego zostanie zapełniona wartością i informacjami o nich. Obejmują one niepowtarzalny identyfikator (uid) a także dane powiązane z kontem, np. identyfikator na Facebooku lub adres e-mail, inne informacje. W przypadku wdrożenia niestandardowego dostawcy uwierzytelniania możesz dodawać własne pola do ładunku uwierzytelniania użytkownika.

W tej sekcji wyjaśniamy, jak połączyć język reguł zabezpieczeń Bazy danych czasu rzeczywistego Firebase z dane uwierzytelniające użytkowników. Łącząc te dwa koncepcje, możesz kontrolować dostęp do danych na podstawie tożsamości użytkownika.

Zmienna `auth`

Zdefiniowana wstępnie zmienna auth w regułach ma wartość null przed uwierzytelniania.

Gdy użytkownik zostanie uwierzytelniony za pomocą Uwierzytelniania Firebase zawiera te atrybuty:

dostawca	używana metoda uwierzytelniania („hasło”, „anonimowa”, „facebook”, „github”, „google”, lub „twitter”).
identyfikator UID	Unikalny identyfikator użytkownika, który musi być unikalny wśród wszystkich dostawców.
token	Zawartość tokena identyfikatora uwierzytelniania Firebase. Zobacz materiał referencyjny dokumentacja dla `auth.token`, aby uzyskać więcej informacji.

Oto przykładowa reguła, która korzysta ze zmiennej auth, aby zapewnić każdy użytkownik może zapisywać dane tylko w ścieżce użytkownika:

{
  "rules": {
    "users": {
      "$user_id": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($user_id)
        ".write": "$user_id === auth.uid"
      }
    }
  }
}

Budowanie struktury bazy danych pod kątem warunków uwierzytelniania

Zwykle warto uporządkować bazę danych w taki sposób, aby ułatwić pisanie Łatwiejsze reguły. Jednym z typowych wzorców do przechowywania danych użytkownika w bazie danych czasu rzeczywistego jest do przechowywania wszystkich użytkowników w jednym węźle users, którego elementy podrzędne są wartości uid dla każdego użytkownika. Jeśli chcesz ograniczyć dostęp do dane w taki sposób, aby tylko zalogowany użytkownik mógł zobaczyć własne dane, reguły będzie wyglądać mniej więcej tak.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

Praca z niestandardowymi żądaniami uwierzytelniania

W przypadku aplikacji, które wymagają niestandardowej kontroli dostępu różnych użytkowników, Uwierzytelnianie Firebase pozwala programistom zgłaszać roszczenia do użytkownika Firebase. Te roszczenia są dostępne w zmiennej auth.token w Twoich regułach. Oto przykład reguł, które korzystają z pola hasEmergencyTowel roszczenie niestandardowe:

{
  "rules": {
    "frood": {
      // A towel is about the most massively useful thing an interstellar
      // hitchhiker can have
      ".read": "auth.token.hasEmergencyTowel === true"
    }
  }
}

Deweloperzy tworzący własne aplikacje niestandardowe tokeny uwierzytelniania mogą opcjonalnie dodawać do tych tokenów deklaracje. Te roszczenia są dostępne w zmiennej auth.token w Twoich regułach.

Istniejące dane a nowe

Zdefiniowana wstępnie zmienna data służy do odwoływania się do danych sprzed wykonywane są operacje zapisu. Natomiast zmienna newData zawiera nowe dane, które będą istnieć po zakończeniu operacji zapisu. newData reprezentuje scalony wynik zapisywania nowych danych i istniejących danych.

Aby to zilustrować, reguła ta pozwoliłaby nam tworzyć nowe rekordy lub usuwać istniejące. tych, ale nie zmieniać istniejących danych niepustych:

// we can write as long as old data or new data does not exist
// in other words, if this is a delete or a create, but not an update
".write": "!data.exists() || !newData.exists()"

Odwołania do danych w innych ścieżkach

Dowolne dane mogą być używane jako kryterium reguł. Użycie wstępnie zdefiniowanego tagu root, data i newData, może uzyskać dostęp do dowolnej ścieżki w takiej postaci, w jakiej istniała przed zdarzeniem zapisu lub po nim.

Rozważmy ten przykład, w którym można wykonywać operacje zapisu, o ile wartość pary klucz-wartość Węzeł /allow_writes/ jest true, węzeł nadrzędny nie ma Ustawiono flagę readOnly i jest element podrzędny o nazwie foo nowo zapisane dane:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

Sprawdzanie danych

Egzekwowanie struktur danych oraz zatwierdzanie formatu i zawartości danych można zrobić za pomocą reguł .validate, które są uruchamiane dopiero po Udało się przyznać dostęp .write regule Poniżej znajduje się przykład Definicja reguły .validate, która zezwala tylko na daty w formacie RRRR-MM-DD z okresu 1900–2099, który sprawdza się za pomocą wyrażenia regularnego.

".validate": "newData.isString() &&
              newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"

Jedynym typem reguł zabezpieczeń, które nie działają kaskadowo, są reguły .validate. Jeśli tak, nie powiedzie się w przypadku żadnego rekordu podrzędnego, cała operacja zapisu zostanie odrzucona. Definicje weryfikacji są też ignorowane przy usuwaniu danych (czyli gdy nowa wartość jest null.

Może się to wydawać banalne, ale w rzeczywistości mają duże znaczenie w kontekście pisania. do zaawansowanych reguł zabezpieczeń Bazy danych czasu rzeczywistego Firebase. Weź pod uwagę te reguły:

{
  "rules": {
    // write is allowed for all paths
    ".write": true,
    "widget": {
      // a valid widget must have attributes "color" and "size"
      // allows deleting widgets (since .validate is not applied to delete rules)
      ".validate": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99
        ".validate": "newData.isNumber() &&
                      newData.val() >= 0 &&
                      newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical
        // /valid_colors/ index
        ".validate": "root.child('valid_colors/' + newData.val()).exists()"
      }
    }
  }
}

Mając na uwadze ten wariant, zwróć uwagę na wyniki tych operacji zapisu:

JavaScript

var ref = db.ref("/widget");

// PERMISSION_DENIED: does not have children color and size
ref.set('foo');

// PERMISSION DENIED: does not have child color
ref.set({size: 22});

// PERMISSION_DENIED: size is not a number
ref.set({ size: 'foo', color: 'red' });

// SUCCESS (assuming 'blue' appears in our colors list)
ref.set({ size: 21, color: 'blue'});

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child('size').set(99);

Objective-C

Uwaga: ta usługa Firebase nie jest dostępna w celu wycinka aplikacji.

FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"];

// PERMISSION_DENIED: does not have children color and size
[ref setValue: @"foo"];

// PERMISSION DENIED: does not have child color
[ref setValue: @{ @"size": @"foo" }];

// PERMISSION_DENIED: size is not a number
[ref setValue: @{ @"size": @"foo", @"color": @"red" }];

// SUCCESS (assuming 'blue' appears in our colors list)
[ref setValue: @{ @"size": @21, @"color": @"blue" }];

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
[[ref child:@"size"] setValue: @99];

Swift

Uwaga: ta usługa Firebase nie jest dostępna w celu wycinka aplikacji.

var ref = FIRDatabase.database().reference().child("widget")

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo")

// PERMISSION DENIED: does not have child color
ref.setValue(["size": "foo"])

// PERMISSION_DENIED: size is not a number
ref.setValue(["size": "foo", "color": "red"])

// SUCCESS (assuming 'blue' appears in our colors list)
ref.setValue(["size": 21, "color": "blue"])

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

Java

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("widget");

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo");

// PERMISSION DENIED: does not have child color
ref.child("size").setValue(22);

// PERMISSION_DENIED: size is not a number
Map<String,Object> map = new HashMap<String, Object>();
map.put("size","foo");
map.put("color","red");
ref.setValue(map);

// SUCCESS (assuming 'blue' appears in our colors list)
map = new HashMap<String, Object>();
map.put("size", 21);
map.put("color","blue");
ref.setValue(map);

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

REST

# PERMISSION_DENIED: does not have children color and size
curl -X PUT -d 'foo' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION DENIED: does not have child color
curl -X PUT -d '{"size": 22}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION_DENIED: size is not a number
curl -X PUT -d '{"size": "foo", "color": "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# SUCCESS (assuming 'blue' appears in our colors list)
curl -X PUT -d '{"size": 21, "color": "blue"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# If the record already exists and has a color, this will
# succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
# will fail to validate
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Teraz przyjrzyjmy się tej samej strukturze, ale z użyciem reguł .write zamiast .validate:

{
  "rules": {
    // this variant will NOT allow deleting records (since .write would be disallowed)
    "widget": {
      // a widget must have 'color' and 'size' in order to be written to this path
      ".write": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99, ONLY IF WE WRITE DIRECTLY TO SIZE
        ".write": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical valid_colors/ index
        // BUT ONLY IF WE WRITE DIRECTLY TO COLOR
        ".write": "root.child('valid_colors/'+newData.val()).exists()"
      }
    }
  }
}

W tym wariancie można wykonać dowolną z tych operacji:

JavaScript

var ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.set({size: 99999, color: 'red'});

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child('size').set(99);

Objective-C

Uwaga: ta usługa Firebase nie jest dostępna w celu wycinka aplikacji.

Firebase *ref = [[Firebase alloc] initWithUrl:URL];

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
[ref setValue: @{ @"size": @9999, @"color": @"red" }];

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
[[ref childByAppendingPath:@"size"] setValue: @99];

Swift

Uwaga: ta usługa Firebase nie jest dostępna w celu wycinka aplikacji.

var ref = Firebase(url:URL)

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.setValue(["size": 9999, "color": "red"])

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.childByAppendingPath("size").setValue(99)

Java

Firebase ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
Map<String,Object> map = new HashMap<String, Object>();
map.put("size", 99999);
map.put("color", "red");
ref.setValue(map);

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child("size").setValue(99);

REST

# ALLOWED? Even though size is invalid, widget has children color and size,
# so write is allowed and the .write rule under color is ignored
curl -X PUT -d '{size: 99999, color: "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# ALLOWED? Works even if widget does not exist, allowing us to create a widget
# which is invalid and does not have a valid color.
# (allowed by the write rule under "color")
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Pokazuje różnice między regułami .write i .validate. Jak wykazano, wszystkie te reguły należy napisać za pomocą atrybutu .validate, a dodatkowo możliwy wyjątek od reguły newData.hasChildren(), która będzie zależała od tego, czy ich usuwanie powinno być dozwolone.

Reguły oparte na zapytaniach

Nie możesz używać reguł jako filtrów, może ograniczyć dostęp do podzbiorów danych za pomocą parametrów zapytań w regułach. Używaj w regułach wyrażeń query., aby przyznawać uprawnienia do odczytu lub zapisu na podstawie: parametrów zapytania.

Na przykład ta reguła oparta na zapytaniach korzysta z reguł zabezpieczeń opartych na użytkownikach i oparte na zapytaniach reguły ograniczające dostęp do danych w kolekcji baskets tylko do koszyka należącego do aktywnego użytkownika:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

Następujące zapytanie, które zawiera parametry zapytania w regule, spowodowałoby :

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

Jednak zapytania, które nie zawierają tych parametrów, nie będą w stanie wykonać parametru błąd PermissionDenied:

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

Możesz też użyć reguł opartych na zapytaniach, aby ograniczyć ilość danych pobieranych przez klienta. za pomocą operacji odczytu.

Na przykład ta reguła ogranicza dostęp z możliwością odczytu tylko do pierwszych 1000 wyniki zapytania w kolejności według priorytetu:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

W regułach zabezpieczeń bazy danych czasu rzeczywistego dostępne są poniższe wyrażenia query..

Wyrażenia reguł opartych na zapytaniach
Wyrażenia	Typ	Opis
query.orderByKey query.orderByPriority query.orderByValue	wartość logiczna	Wartość prawda w przypadku zapytań posortowanych według klucza, priorytetu lub wartości. W przeciwnym razie ma wartość Fałsz.
query.orderByChild	ciąg znaków wartość null	Użyj ciągu znaków do reprezentowania ścieżki względnej do węzła podrzędnego. Przykład: `query.orderByChild === "address/zip"` Jeśli zapytanie nie jest w kolejności według węzła podrzędnego, ta wartość ma wartość null.
query.startAt query.endAt query.EqualTo	ciąg znaków liczba wartość logiczna wartość null	Pobiera granice wykonywanego zapytania lub zwraca wartość null, jeśli występuje nie ma ustalonej granicy.
zapytanie.limitToFirst query.limitToLast	liczba wartość null	Pobiera limit wykonywanego zapytania lub zwraca wartość null, jeśli istnieje brak limitu.

Dalsze kroki

Po omówieniu warunków możemy uzyskać bardziej zaawansowane rozumieją Zasady i gotowy do:

Naucz się radzić sobie z podstawowymi przypadkami użycia i nauczysz się przepływów pracy związanych z tworzeniem, testowanie i wdrażanie reguł:

Więcej informacji o pełnym zestawie wstępnie zdefiniowanych zmiennych reguł, których możesz używać do tworzenia warunków.
Napisać reguły dotyczące typowych scenariuszy.
Poszerzaj swoją wiedzę, sprawdzając sytuacje, w których musisz rozpoznawać niezabezpieczone Reguły i ich unikać.
Dowiedz się więcej o Pakiecie emulatorów lokalnych Firebase i o tym, jak go używać do testowania reguł.
Przejrzyj dostępne metody wdrażania reguł.

Poznaj funkcje reguł, które są specyficzne dla Bazy danych czasu rzeczywistego:

Dowiedz się, jak zindeksować bazę danych czasu rzeczywistego.
Zapoznaj się z interfejsem REST API do wdrażania reguł.

Korzystanie z warunków w regułach zabezpieczeń bazy danych czasu rzeczywistego

Używanie zmiennych $ do przechwytywania segmentów ścieżki

Uwierzytelnianie

Zmienna auth

Budowanie struktury bazy danych pod kątem warunków uwierzytelniania

Praca z niestandardowymi żądaniami uwierzytelniania

Istniejące dane a nowe

Odwołania do danych w innych ścieżkach

Sprawdzanie danych

JavaScript

Objective-C

Swift

Java

REST

JavaScript

Objective-C

Swift

Java

REST

Reguły oparte na zapytaniach

Dalsze kroki

Zmienna `auth`