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

Ten przewodnik jest kontynuacją przewodnika dotyczącego podstaw języka reguł zabezpieczeń Firebase . Dowiesz się z niego, jak dodawać warunki do reguł zabezpieczeń Bazy danych czasu rzeczywistego Firebase.

Podstawowym elementem składowym reguł zabezpieczeń Bazy danych czasu rzeczywistego jest warunek. Warunek to wyrażenie logiczne, które określa, czy dana operacja powinna zostać 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 tworzenie bardziej złożonych warunków, które mogą:

• sprawdzać uwierzytelnianie użytkownika,
• oceniać istniejące dane na podstawie nowo przesłanych danych,
• uzyskiwać dostęp do różnych części bazy danych i porównywać je,
• sprawdzać poprawność danych przychodzących,
• wykorzystywać strukturę zapytań przychodzących w logice zabezpieczeń.

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

Możesz przechwytywać części ś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 do zadeklarowania reguły .validate, która zapewnia, że widget nie ma elementów podrzędnych innych niż title i color. Każda operacja zapisu, która spowodowałaby 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 uwierzytelnienia użytkownika. Na przykład aplikacja może zezwalać na zapisywanie danych tylko zalogowanym użytkownikom.

Jeśli Twoja aplikacja korzysta z uwierzytelniania Firebase, zmienna request.auth zawiera informacje o uwierzytelnieniu klienta, który wysyła żądanie danych. Więcej informacji o request.auth znajdziesz w dokumentacji.

Firebase Authentication integruje się z Firebase Realtime Database, co pozwala kontrolować dostęp do danych na podstawie warunków dla poszczególnych użytkowników. Gdy użytkownik się uwierzytelni, zmienna auth w regułach zabezpieczeń Bazy danych czasu rzeczywistej zostanie wypełniona informacjami o użytkowniku. Te informacje obejmują unikalny identyfikator (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ł zabezpieczeń Bazy danych czasu rzeczywistej Firebase z informacjami o uwierzytelnianiu użytkowników. Dzięki połączeniu tych 2 koncepcji możesz 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, zanim nastąpi uwierzytelnienie.

Gdy użytkownik zostanie uwierzytelniony w usłudze Uwierzytelnianie Firebase zmienna będzie zawierać te atrybuty:

Oto przykład reguły, 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"
      }
    }
  }
}

Struktura bazy danych obsługująca warunki uwierzytelniania

Zwykle warto jest tak skonstruować bazę danych, aby ułatwić pisanie Security Rules Jednym z typowych 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 każdego użytkownika. Jeśli chcesz ograniczyć dostęp do tych danych tak, aby tylko zalogowany użytkownik mógł zobaczyć swoje dane, reguły powinny 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 deklaracji dla użytkownika Firebase. Te deklaracje są dostępne w zmiennej auth.token w regułach. Oto przykład reguł, które korzystają z niestandardowej deklaracji hasEmergencyTowel:

{
  "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 deklaracje. Te deklaracje są dostępne w zmiennej auth.token w regułach.

Dane istniejące a nowe

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ą istniały, jeśli operacja zapisu się powiedzie. newData reprezentuje scalony wynik nowych danych, które są zapisywane, i danych istniejących.

Aby to zilustrować, ta reguła umożliwiłaby nam tworzenie nowych rekordów lub usuwanie istniejących, ale nie wprowadzanie zmian w istniejących danych, które nie są wartością 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. Za pomocą wstępnie zdefiniowanych zmiennych root, data i newData możemy uzyskać dostęp do dowolnej ścieżki w stanie przed lub po zdarzeniu zapisu.

Rozważ 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 i 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 treści danych powinno odbywać się za pomocą reguł .validate, które są uruchamiane tylko wtedy, gdy reguła .write zakończy się powodzeniem i przyzna dostęp. Poniżej znajduje się przykładowa definicja reguły .validate, która zezwala tylko na daty w formacie RRRR-MM-DD w latach 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])$/)"

Reguły .validate są jedynym typem 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. Ponadto definicje sprawdzania poprawności są ignorowane, gdy dane są usuwane (czyli gdy nowa zapisywana wartość to null).

Mogą się one wydawać trywialne, ale w rzeczywistości są ważnymi funkcjami do tworzenia zaawansowanych reguł zabezpieczeń Bazy danych czasu rzeczywistej Firebase. Rozważ 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 używając 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ć napisane za pomocą .validate, z 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 parametrów zapytania w regułach. Użyj wyrażeń query. w regułach, aby przyznać dostęp do odczytu lub zapisu na podstawie parametrów zapytania.

Na przykład ta reguła oparta na zapytaniu 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, zakończy się powodzeniem:

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

Jednak zapytania, które nie zawierają parametrów w regule, zakończą się niepowodzeniem z powodu błędu PermissionDenied:

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

Możesz też używać reguł opartych na zapytaniach, aby ograniczyć ilość danych, które klient pobiera 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 rzeczywistej dostępne są te wyrażenia query.:

Dalsze kroki

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

Dowiedzieć się, jak obsługiwać podstawowe przypadki użycia, oraz poznać proces tworzenia, testowania i wdrażania Security Rules:

• Poznać pełny zestaw wstępnie zdefiniowanych Security Rules zmiennych, których możesz używać do tworzenia warunków.
• Pisać reguły, które rozwiązują typowe problemy.
• Poszerzyć swoją wiedzę, analizując sytuacje, w których musisz wykryć i unikać reguł, które nie są bezpieczne.
• Dowiedzieć się więcej o Pakiecie emulatorów lokalnych Firebase i o tym, jak go używać do testowania Security Rules.
• Zapoznać się z metodami wdrażania reguł Security Rules.

Poznać funkcje, które są specyficzne dla Realtime Database:Security Rules

• Dowiedzieć się, jak indeksować Realtime Database.
• Zapoznać się z interfejsem API REST do wdrażania Security Rules.