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

Ten przewodnik jest kontynuacją przewodnika poznaj podstawowy język 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 zabroniona. W przypadku podstawowych reguł używanie literałów true i false jako warunków sprawdza się doskonale. Język reguł zabezpieczeń Bazy danych czasu rzeczywistego umożliwia jednak pisanie bardziej złożonych warunków, które mogą:

• Sprawdzanie uwierzytelniania użytkownika
• Ocena dotychczasowych danych na podstawie nowo przesłanych danych
• uzyskiwać dostęp do różnych części bazy danych i porównywać je ze sobą,
• Sprawdzanie danych przychodzących
• Używanie struktury zapytań przychodzących w logice 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 $. Działa to jak 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ć .validate regułę, która zapewnia, że element 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 }
    }
  }
}

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 korzysta z uwierzytelniania Firebase, zmienna request.auth zawiera informacje o uwierzytelnianiu klienta, który wysyła żądanie danych. Więcej informacji o request.auth znajdziesz w dokumentacji.

Firebase Authentication jest zintegrowana z usługą Firebase Realtime Database, co pozwala kontrolować dostęp do danych na poziomie poszczególnych użytkowników za pomocą warunków. Gdy użytkownik się uwierzytelni, zmienna auth w regułach zabezpieczeń Bazy danych czasu rzeczywistego zostanie wypełniona informacjami o użytkowniku. Obejmują one unikalny identyfikator użytkownika (uid), a także dane połączonego konta, takie jak identyfikator Facebooka 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 dowiesz się, jak połączyć język reguł bezpieczeństwa Bazy danych czasu rzeczywistego Firebase z informacjami o uwierzytelnianiu użytkowników. Łącząc te 2 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, zanim nastąpi uwierzytelnianie.

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

Oto przykładowa reguła, która używa zmiennej auth, aby zapewnić, że każdy użytkownik może zapisywać dane tylko w ścieżce przypisanej do 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"
      }
    }
  }
}

Strukturyzowanie bazy danych pod kątem obsługi warunków uwierzytelniania

Zwykle warto tak zaprojektować bazę danych, aby ułatwić pisanie zapytańRules. Jednym z najczęstszych sposobó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 tak, aby tylko zalogowany użytkownik mógł zobaczyć swoje dane, Twoje reguły będą wyglądać mniej więcej tak:

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

Korzystanie z niestandardowych roszczeń uwierzytelniania

W przypadku aplikacji, które wymagają niestandardowej kontroli dostępu dla różnych użytkowników, Firebase Authenticationumożliwia deweloperom ustawianie roszczeń dotyczących użytkownika Firebase. Te roszczenia są dostępne w zmiennejauth.token w regułach. Oto przykład reguł, które korzystają z hasEmergencyTowelniestandardowego roszczenia:

{
  "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 niestandardowe tokeny uwierzytelniania mogą opcjonalnie dodawać do nich roszczenia. Te roszczenia są dostępne w zmiennej auth.token w regułach.

Dane dotychczasowe a nowe dane

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

Na przykład 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ą wartościami null:

// 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ływanie się do danych w innych ścieżkach

Jako kryterium reguł można używać dowolnych danych. Korzystając z predefiniowanych zmiennych root, data i newData, możemy uzyskać dostęp do dowolnej ścieżki w stanie sprzed lub po zdarzeniu zapisu.

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ę element podrzędny o nazwie foo:

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

Sprawdzanie poprawności danych

Wymuszanie struktur danych oraz sprawdzanie formatu i zawartości danych powinno odbywać się za pomocą .validatereguł, które są uruchamiane tylko wtedy, gdy .writereguła przyznająca dostęp zakończy się powodzeniem. Poniżej znajduje się przykładowa definicja reguły .validate, która zezwala tylko na daty w formacie RRRR-MM-DD z zakresu 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])$/)"

.validate to jedyny typ reguły zabezpieczeń, który nie jest kaskadowy. Jeśli w przypadku dowolnego rekordu podrzędnego nie zostanie spełniona żadna reguła weryfikacji, cała operacja zapisu zostanie odrzucona. Dodatkowo definicje weryfikacji są ignorowane podczas usuwania danych (czyli gdy zapisywana nowa wartość to null).

Mogą się one wydawać nieistotne, ale w rzeczywistości są ważnymi funkcjami, które umożliwiają tworzenie 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, przyjrzyj się wynikom tych operacji zapisu:

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);

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];

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);

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);

# 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

Przyjrzyjmy się teraz 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:

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);

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];

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)

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);

# 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 widać, wszystkie te reguły powinny być zapisane przy użyciu .validate, z możliwym wyjątkiem reguły newData.hasChildren(), która zależy od tego, czy usuwanie powinno być dozwolone.

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 w regułach parametrów zapytania. W regułach używaj wyrażeń query., aby przyznawać dostęp do odczytu lub zapisu na podstawie parametrów zapytania.

Na przykład ta reguła oparta na zapytaniu korzysta z reguł bezpieczeństwa opartych na użytkownikach i reguł opartych na zapytaniach, aby ograniczyć dostęp do danych w kolekcji baskets tylko do koszyków, których właścicielem jest aktywny użytkownik:

"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, będą kończyć się niepowodzeniem z błędem 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 podczas 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..

Dalsze kroki

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

Dowiedz się, jak obsługiwać podstawowe przypadki użycia, oraz poznaj przepływ pracy związany z opracowywaniem, testowaniem i wdrażaniem Rules:

• Poznaj pełny zestaw predefiniowanych Rules zmiennych, których możesz używać do tworzenia warunków.
• Twórz reguły, które dotyczą typowych scenariuszy.
• Poszerz swoją wiedzę, zapoznając się z sytuacjami, w których musisz rozpoznać i unikać niezabezpieczonych reguł.
• Dowiedz się więcej o Pakiecie emulatorów lokalnych Firebase i o tym, jak możesz go używać do testowaniaRules.
• Sprawdź metody dostępne w przypadku wdrażaniaRules.

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

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