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

Ten przewodnik opiera się na przewodniku po podstawowym języku 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 zostać dozwolona, czy odrzucona. W przypadku podstawowych reguł stosowanie literali true i false jako warunków sprawdza się doskonale. Jednak język reguł zabezpieczeń Bazy danych czasu rzeczywistego umożliwia tworzenie bardziej złożonych warunków, które mogą:

• Sprawdzanie uwierzytelniania użytkowników
• Ocena dotychczasowych danych na tle nowo przesłanych danych
• uzyskiwać dostęp do różnych części bazy danych i je porównywać,
• Sprawdzanie danych przychodzących
• Korzystanie z struktury przychodzących zapytań do celów logiki bezpieczeństwa

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

Możesz rejestrować fragmenty ścieżki do odczytu lub zapisu, deklarując zmienne rejestrujące z prefiksem $. Służy jako symbol wieloznaczny i przechowuje wartość tego klucza na potrzeby warunków 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 z stałymi nazwami ścieżek. W tym przykładzie używamy zmiennej $other, aby zadeklarować regułę .validate, która zapewnia, że widget nie ma żadnych elementów podrzędnych poza title i color. Każdy zapis, który spowoduje 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 wzorów reguł zabezpieczeń jest kontrolowanie dostępu na podstawie stanu uwierzytelniania użytkownika. Możesz na przykład zezwolić na zapisywanie danych tylko zalogowanym użytkownikom.

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

Firebase Authentication integruje się z Firebase Realtime Database, aby umożliwić Ci kontrolowanie dostępu do danych na poziomie użytkownika za pomocą warunków. Gdy użytkownik uwierzytelni się, zmienna auth w regułach bezpieczeństwa bazy danych czasu rzeczywistego zostanie wypełniona informacjami o użytkowniku. Te informacje obejmują unikalny identyfikator użytkownika (uid), a także dane powiązanego 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 pakietu danych uwierzytelniania użytkownika.

Z tej sekcji dowiesz się, jak połączyć język reguł bezpieczeństwa Bazy danych czasu rzeczywistego Firebase z informacjami uwierzytelniania użytkowników. Łącząc te 2 koncepcje, możesz kontrolować dostęp do danych na podstawie tożsamości użytkownika.

Zmienna auth

Zmienna auth w regułach jest null przed uwierzytelnieniem.

Po uwierzytelnieniu użytkownika za pomocą usługi Uwierzytelnianie Firebaseatrybut ten 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ć tylko w ścieżce konkretnego 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"
      }
    }
  }
}

Struktura bazy danych, która obsługuje warunki uwierzytelniania

Zwykle warto uporządkować bazę danych w sposób, który ułatwia pisanie.Rules Jednym z popularnych sposobów przechowywania danych użytkownika w Realtime Database jest przechowywanie wszystkich użytkowników w pojedynczym węźle users, którego 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ł widzieć własne dane, Twoje reguły będą wyglądać mniej więcej tak.

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

Praca z niestandardowymi oświadczeniami 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 elementy są dostępne w składowej auth.token w regułach. Oto przykład reguł, które korzystają z roszczenia niestandardowego 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 tokeny uwierzytelniania, mogą opcjonalnie dodawać do nich oświadczenia. Te elementy żądania są dostępne w sprawie zmiennej auth.token w Twoich regułach.

Istniejące dane a nowe dane

Zmienna wstępnie zdefiniowana 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 scalone nowe dane i istniejące dane.

Ta reguła pozwoliłaby nam tworzyć nowe rekordy i usuwać istniejące, ale nie wprowadzać zmian w dotychczasowych 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ływanie się do danych w innych ścieżkach

Jako kryteria reguł możesz używać dowolnych danych. Korzystając z wstępnie zdefiniowanych zmiennych root, data i newData, możemy uzyskać dostęp do dowolnej ścieżki w postaci, jaką miała ona 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 ustawionego znacznika readOnly i w nowo zapisanych danych jest element podrzędny o nazwie foo:

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

Weryfikacja danych

Zmuszanie struktur danych i sprawdzanie formatu oraz zawartości danych należy przeprowadzać za pomocą reguł .validate, które są wykonywane tylko 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, co jest 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 są jedynym typem reguł zabezpieczeń, które nie działają kaskadowo. Jeśli którakolwiek z reguł walidacji nie zadziała w przypadku dowolnego rekordu podrzędnego, cała operacja zapisu zostanie odrzucona. Dodatkowo definicje weryfikacji są ignorowane, gdy dane są usuwane (czyli gdy nowa wartość zapisywana jest jako null).

Te punkty mogą wydawać się trywialne, ale w istocie są ważnymi funkcjami umożliwiającymi tworzenie skutecznych reguł zabezpieczeń Bazy danych czasu rzeczywistego Firebase. Weź pod uwagę te zasady:

{
  "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, sprawdź wyniki 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

Teraz przyjrzyjmy się tej samej strukturze, ale z regułami .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łaby się sukcesem:

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

Ilustracja przedstawiająca różnice między regułami .write i .validate. Jak pokazano, wszystkie te reguły powinny być zapisane za pomocą funkcji .validate, z możliwym wyjątkiem reguły newData.hasChildren(), która zależy od tego, czy zezwolenie na usunięcia ma być dozwolone.

Reguły oparte na zapytaniach

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

Na przykład ta reguła oparta na zapytaniu używa reguł bezpieczeństwa opartych na użytkowniku i reguł opartych na zapytaniu, aby ograniczyć dostęp do danych w zbiorze baskets tylko do koszyków zakupowych 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
}

Poniższe zapytanie, które zawiera parametry zapytania w regułach, zakończy się powodzeniem:

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

Zapytania, które nie zawierają parametrów z reguły, będą jednak obarczone błędem PermissionDenied:

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

Za pomocą reguł opartych na zapytaniach możesz też ograniczyć ilość danych pobieranych przez klienta za pomocą 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 warunków masz już większą wiedzę na temat Rules i możesz:

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

• Poznaj pełny zestaw zdefiniowanych wstępnie Rules zmiennych, których możesz używać do tworzenia warunków.
• Utwórz reguły, które będą odpowiadać typowym scenariuszom.
• Poszerzaj swoją wiedzę, analizując sytuacje, w których musisz wykrywać i unikać niepewnych reguł.
• Dowiedz się więcej o Pakiecie emulatorów lokalnych Firebase i o tym, jak go używać do testowania Rules.
• Zapoznaj się z dostępnymi metodami wdrażania Rules.

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.