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

Ten przewodnik opiera się na przewodniku Podstawy języka reguł zabezpieczeń Firebase i pokazuje, jak dodawać warunki do reguł zabezpieczeń bazy danych czasu rzeczywistego Firebase.

Podstawowym elementem reguł zabezpieczeń Bazy danych czasu rzeczywistego jest warunek. Warunek to wyrażenie logiczne, które określa, czy dana operacja powinna być dozwolona czy odrzucona. W przypadku podstawowych reguł używanie literałów true i false jako warunków działa idealnie. Jednak język reguł zabezpieczeń Bazy danych czasu rzeczywistego umożliwia pisanie bardziej złożonych warunków, które mogą:

• Sprawdzanie uwierzytelniania użytkowników
• Porównywanie dotychczasowych danych z nowo przesłanymi
• Uzyskiwanie dostępu do różnych części bazy danych i ich porównywanie
• Weryfikacja danych przychodzących
• Używanie 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, deklarując zmienne przechwytywania z prefiksem $. Służy jako symbol wieloznaczny i przechowuje wartość tego klucza do użycia w warunkach 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')"
        }
      }
    }
  }
}

Zmiennych dynamicznych $ można też używać równolegle ze stałymi nazwami ścieżek. W tym przykładzie używamy zmiennej $other, aby zadeklarować regułę .validate, która zapewnia, że widget nie ma innych elementów podrzędnych niż title i color. Każdy zapis, który spowodowałby utworzenie dodatkowych elementów podrzędnych, zakoń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 }
    }
  }
}

Uwaga: klucze ścieżki są zawsze ciągami znaków. Z tego powodu należy pamiętać, że próba porównania zmiennej $ z liczbą zawsze zakończy się niepowodzeniem. Można to poprawić, konwertując liczbę na ciąg znaków (np. $key === newData.val()+'').

Uwierzytelnianie

Jednym z najczęstszych wzorców reguł zabezpieczeń jest kontrolowanie dostępu na podstawie stanu uwierzytelniania użytkownika. Na przykład aplikacja może zezwalać na zapisywanie danych tylko zalogowanym użytkownikom.

Jeśli aplikacja używa Uwierzytelniania Firebase, zmienna request.auth zawiera informacje uwierzytelniające klienta, który żąda danych. Więcej informacji o request.auth znajdziesz w dokumentacji referencyjnej.

Usługa Firebase Authentication jest zintegrowana z Firebase Realtime Database, co pozwala kontrolować dostęp do danych na poziomie użytkownika za pomocą warunków. Gdy użytkownik zostanie uwierzytelniony, zmienna auth w regułach zabezpieczeń bazy danych czasu rzeczywistego zostanie wypełniona informacjami o użytkowniku. Te informacje obejmują unikalny identyfikator (uid), a także dane połączonego konta, takie jak identyfikator na Facebooku lub adres e-mail, oraz inne informacje. Jeśli wdrożysz niestandardowego dostawcę uwierzytelniania, możesz dodać 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 informacjami uwierzytelniającymi użytkowników. Połączenie tych 2 koncepcji pozwala kontrolować dostęp do danych na podstawie tożsamości użytkownika.

Zmienna auth

Wstępnie zdefiniowana zmienna auth w regułach ma wartość null przed uwierzytelnieniem.

Po uwierzytelnieniu użytkownika za pomocą Uwierzytelniania Firebase będzie on zawierał te atrybuty:

dostawca	Użyta metoda uwierzytelniania („password”, „anonymous”, „facebook”, „github”, „google” lub „twitter”).
uid	Unikalny identyfikator użytkownika, który jest unikalny dla wszystkich dostawców.
token	Zawartość tokena identyfikatora Firebase Auth. Więcej informacji znajdziesz w dokumentacji referencyjnej auth.token.

Oto przykładowa reguła, która używa zmiennej auth, aby zapewnić, że każdy użytkownik może zapisywać tylko w ścieżce przeznaczonej dla niego:

{
  "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"
      }
    }
  }
}

Struktura bazy danych obsługująca warunki uwierzytelniania

Zwykle warto ustrukturyzować bazę danych w sposób, który ułatwia zapisywanie Security Rules. Jednym z typowych wzorców przechowywania danych użytkowników w Realtime Database jest przechowywanie wszystkich użytkowników w jednym węźle users, którego elementami podrzędnymi są wartości uid dla każdego użytkownika. Jeśli chcesz ograniczyć dostęp do tych danych, aby tylko zalogowany użytkownik mógł zobaczyć swoje dane, reguły będą wyglądać mniej więcej tak:

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

Praca z niestandardowymi deklaracjami uwierzytelniania

W przypadku aplikacji, które wymagają niestandardowej kontroli dostępu dla różnych użytkowników, Firebase Authentication umożliwia deweloperom ustawianie uprawnień użytkownika Firebase. Te oświadczenia są dostępne w zmiennej auth.token w Twoich regułach. Oto przykład reguł, które korzystają z niestandardowego oświadczenia hasEmergencyTowel:

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

Deweloperzy, którzy tworzą własne niestandardowe tokeny uwierzytelniania, mogą opcjonalnie dodawać do nich oświadczenia. Te oświadczenia są dostępne w zmiennej auth.token w regułach.

Istniejące dane a nowe dane

Wstępnie zdefiniowana zmienna data służy do odwoływania się do danych przed wykonaniem operacji zapisu. Z kolei zmienna newData zawiera nowe dane, które będą istnieć, jeśli operacja zapisu się powiedzie. newData reprezentuje scalony wynik nowych zapisywanych danych i istniejących danych.

Ta reguła umożliwia tworzenie nowych rekordów lub usuwanie istniejących, ale nie pozwala na wprowadzanie zmian w istniejących danych, które nie są puste:

// 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()"

Sprawdź, czy nie ma wartości null lub nieprawidłowych danych. Błędy w regułach prowadzą do odrzucenia operacji.

Odwoływanie się do danych w innych ścieżkach

Wszystkie dane mogą być używane jako kryteria reguł. Za pomocą wstępnie zdefiniowanych zmiennych root, data i newData możemy uzyskać dostęp do dowolnej ścieżki, która istniała przed zdarzeniem zapisu lub po nim.

Rozważmy ten przykład, który zezwala na operacje zapisu, o ile wartość węzła /allow_writes/ to true, węzeł nadrzędny nie ma ustawionej flagi readOnly, a w nowo zapisanych danych znajduje się węzeł podrzędny o nazwie foo:

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

Weryfikuję dane

Egzekwowanie struktur danych oraz sprawdzanie formatu i zawartości danych powinno odbywać się za pomocą reguł .validate, które są uruchamiane dopiero po tym, jak reguła .write przyzna dostęp. Poniżej znajdziesz przykładową definicję reguły .validate, która zezwala tylko na daty w formacie RRRR-MM-DD z lat 1900–2099. Jest to sprawdzane 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])$/)"

Wypróbuj w JSFiddle: kliknij tutaj, aby zobaczyć, jak to działa. Spróbuj wpisać inne wartości w polu do wprowadzania danych.

Reguły .validate to jedyny typ reguł zabezpieczeń, które nie są kaskadowe. Jeśli jakakolwiek reguła sprawdzania poprawności nie powiedzie się w przypadku dowolnego rekordu podrzędnego, cała operacja zapisu zostanie odrzucona. Dodatkowo definicje walidacji są ignorowane, gdy dane są usuwane (czyli gdy nowa zapisywana wartość to null).

Uwaga: reguły .validate są oceniane tylko w przypadku wartości innych niż null i nie są kaskadowe.

Te kwestie mogą wydawać się błahe, ale w rzeczywistości są to ważne funkcje, które pozwalają pisać skuteczne reguły 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, spójrz 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 przypadku celu App Clip.

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 przypadku celu App Clip.

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 każda z tych operacji zakończy się powodzeniem:

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 przypadku celu App Clip.

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 przypadku celu App Clip.

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

Ilustruje to różnice między regułami .write i .validate. Jak pokazano, wszystkie te reguły powinny być zapisane przy użyciu .validate, z wyjątkiem reguły newData.hasChildren(), która zależy od tego, czy usuwanie powinno być dozwolone.

Uwaga: reguły sprawdzania poprawności nie mają całkowicie zastąpić kodu sprawdzania poprawności danych w aplikacji. Zalecamy również sprawdzanie poprawności danych wejściowych po stronie klienta, aby zapewnić najlepszą wydajność i komfort użytkowania, gdy aplikacja jest offline.

Reguły oparte na zapytaniach

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

Na przykład ta reguła oparta na zapytaniach używa reguł zabezpieczeń opartych na użytkownikach i reguł opartych na zapytaniach, aby ograniczyć dostęp do danych w kolekcji baskets tylko do koszyków należących do aktywnego użytkownika:

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

To zapytanie, które zawiera parametry zapytania w regule, zostanie wykonane:

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

Jednak zapytania, które nie zawierają parametrów w regule, nie powiodą się i wystąpi błąd PermissionDenied:

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

Możesz też używać reguł opartych na zapytaniach, aby ograniczyć ilość danych pobieranych przez klienta w ramach operacji odczytu.

Na przykład ta reguła ogranicza dostęp do odczytu tylko do pierwszych 1000 wyników zapytania, uporządkowanych 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ą te wyrażenia query..

Wyrażenia reguł oparte na zapytaniach
Expression	Typ	Opis
query.orderByKey query.orderByPriority query.orderByValue	wartość logiczna	Wartość „true” w przypadku zapytań uporządkowanych według klucza, priorytetu lub wartości. W przeciwnym razie ma wartość Fałsz.
query.orderByChild	string null	Użyj ciągu znaków, aby przedstawić ścieżkę względną do węzła podrzędnego. Na przykład: query.orderByChild === "address/zip". Jeśli zapytanie nie jest uporządkowane według węzła podrzędnego, ta wartość jest równa null.
query.startAt query.endAt query.equalTo	string number boolean null	Pobiera granice wykonywanego zapytania lub zwraca wartość null, jeśli nie ustawiono żadnej granicy.
query.limitToFirst query.limitToLast	number null	Pobiera limit wykonywanego zapytania lub zwraca wartość null, jeśli nie ustawiono limitu.

Dalsze kroki

Po omówieniu warunków masz już bardziej zaawansowaną wiedzę na temat Security Rules i możesz:

Dowiedz się, jak obsługiwać podstawowe przypadki użycia oraz jak wygląda proces tworzenia, testowania i wdrażania Security Rules:

• Dowiedz się więcej o pełnym zestawie wstępnie zdefiniowanych Security Rules zmiennych, których możesz używać do tworzenia warunków.
• Twórz reguły, które dotyczą typowych scenariuszy.
• Poszerz swoją wiedzę, analizując sytuacje, w których musisz rozpoznać i unikać niebezpiecznych reguł.
• Dowiedz się więcej o Pakiecie emulatorów lokalnych Firebase i o tym, jak możesz go używać do testowania Security Rules.
• Sprawdź dostępne metody wdrażania Security Rules.

Poznaj funkcje Security Rules, które są dostępne w Realtime Database:

• Dowiedz się, jak zindeksować Realtime Database.
• Zapoznaj się z interfejsem API typu REST do wdrażania Security Rules.