Bezpieczeństwo może być jednym z najbardziej złożonych elementów układanki tworzenia aplikacji. W większości aplikacji programiści muszą zbudować i uruchomić serwer, który obsługuje uwierzytelnianie (kim jest użytkownik) i autoryzację (co może zrobić użytkownik).
Reguły zabezpieczeń Firebase usuwają warstwę środkową (serwerową) i umożliwiają określenie uprawnień opartych na ścieżkach dla klientów, którzy łączą się bezpośrednio z Twoimi danymi. Skorzystaj z tego przewodnika, aby dowiedzieć się więcej o stosowaniu reguł do żądań przychodzących.
Wybierz produkt, aby dowiedzieć się więcej o jego zasadach.
Cloud Firestore
Podstawowa struktura
Reguły zabezpieczeń Firebase w Cloud Firestore i Cloud Storage mają następującą strukturę i składnię:
service <<name>> {
// Match the resource path.
match <<path>> {
// Allow the request if the following conditions are true.
allow <<methods>> : if <<condition>>
}
}
Podczas tworzenia reguł należy zrozumieć następujące kluczowe pojęcia:
- Żądanie: metoda lub metody wywołane w instrukcji
allow
. To są metody, na które pozwalasz. Standardowe metody to:get
,list
,create
,update
idelete
. Doread
iwrite
metody wygoda umożliwić szeroki dostęp do odczytu i zapisu na określonej ścieżce bazy danych lub pamięci masowej. - Ścieżka: baza danych lub lokalizacja magazynu reprezentowana jako ścieżka identyfikatora URI.
- Reguła: instrukcja
allow
, która zawiera warunek, który zezwala na żądanie, jeśli uzyska wartość true.
Reguły bezpieczeństwa w wersji 2
Od maja 2019 r. Dostępna jest wersja 2 reguł zabezpieczeń Firebase. Wersja 2 reguł zmienia zachowanie rekursywnych symboli wieloznacznych {name=**}
. Jeśli planujesz używać zapytań o grupy kolekcji, musisz użyć wersji 2. Musisz wyrazić zgodę na wersję 2, rules_version = '2';
pierwsza linia reguł bezpieczeństwa:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
Pasujące ścieżki
Wszystkie stwierdzenia o dopasowaniu powinny wskazywać na dokumenty, a nie kolekcje. Instrukcja dopasowania może wskazywać na konkretny dokument, np. match /cities/SF
lub użyć symboli wieloznacznych, aby wskazać dowolny dokument w określonej ścieżce, np. match /cities/{city}
.
W powyższym przykładzie instrukcja match używa składni wieloznacznej {city}
. Oznacza to, że reguła dotyczy każdego dokumentu w kolekcji cities
, takiego jak /cities/SF
lub /cities/NYC
. Po oszacowaniu wyrażeń allow
w instrukcji dopasowania zmienna city
zostanie rozstrzygnięta na nazwę dokumentu miasta, na przykład SF
lub NYC
.
Pasujące podkolekcje
Dane w Cloud Firestore są zorganizowane w kolekcje dokumentów, a każdy dokument może rozszerzać hierarchię o podkolekcje. Ważne jest, aby zrozumieć, w jaki sposób reguły bezpieczeństwa współdziałają z danymi hierarchicznymi.
Rozważ sytuację, w której każdy dokument w kolekcji cities
zawiera podkolekcję landmarks
. Reguły bezpieczeństwa obowiązują tylko w dopasowanej ścieżce, więc kontrole dostępu zdefiniowane w kolekcji cities
nie mają zastosowania do podkolekcji landmarks
. Zamiast tego napisz wyraźne reguły kontrolujące dostęp do kolekcji podrzędnych:
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
allow read, write: if <condition>;
// Explicitly define rules for the 'landmarks' subcollection
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
Podczas zagnieżdżania instrukcji match
ścieżka instrukcji match
wewnętrznego jest zawsze względna w stosunku do ścieżki instrukcji match
zewnętrznego. Następujące zestawy reguł są zatem równoważne:
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city}/landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
Rekurencyjne symbole wieloznaczne
Jeśli chcesz, aby reguły miały zastosowanie do arbitralnie głębokiej hierarchii, użyj rekurencyjnej składni wieloznacznej, {name=**}
:
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{document=**} {
allow read, write: if <condition>;
}
}
}
W przypadku rekurencyjnej składni symboli wieloznacznych zmienna wieloznaczna będzie zawierać cały pasujący segment ścieżki, nawet jeśli dokument znajduje się w głęboko zagnieżdżonej kolekcji podrzędnej. Na przykład reguły wymienione powyżej pasowałyby do dokumentu znajdującego się w /cities/SF/landmarks/coit_tower
, a wartość zmiennej document
to SF/landmarks/coit_tower
.
Należy jednak pamiętać, że zachowanie rekursywnych symboli wieloznacznych zależy od wersji reguł.
Wersja 1
Reguły bezpieczeństwa domyślnie używają wersji 1. W wersji 1 rekursywne symbole wieloznaczne pasują do co najmniej jednego elementu ścieżki. Nie pasują do pustej ścieżki, więc match /cities/{city}/{document=**}
pasuje do dokumentów w podkolekcjach, ale nie w kolekcji cities
, podczas gdy match /cities/{document=**}
dopasowuje oba dokumenty w kolekcja cities
i podkolekcje.
Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.
Wersja 2
W wersji 2 reguł bezpieczeństwa rekursywne symbole wieloznaczne odpowiadają zeru lub większej liczbie elementów ścieżki. match/cities/{city}/{document=**}
dopasowuje dokumenty we wszystkich podkolekcjach, a także dokumenty w kolekcji cities
.
Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2';
u góry reguł bezpieczeństwa:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{city}/{document=**} {
allow read, write: if <condition>;
}
}
}
Możesz mieć co najwyżej jeden rekursywny symbol wieloznaczny na każdą instrukcję dopasowania, ale w wersji 2 możesz umieścić ten symbol w dowolnym miejscu w instrukcji dopasowania. Na przykład:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the songs collection group
match /{path=**}/songs/{song} {
allow read, write: if <condition>;
}
}
}
Jeśli używasz zapytań o grupy kolekcji , musisz użyć wersji 2, zobacz zabezpieczanie zapytań o grupy kolekcji .
Pokrywające się stwierdzenia dopasowania
Dokument może pasować do więcej niż jednej instrukcji match
. W przypadku, gdy wiele wyrażeń allow
pasuje do żądania, dostęp jest dozwolony, jeśli którykolwiek z warunków jest true
:
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the 'cities' collection.
match /cities/{city} {
allow read, write: if false;
}
// Matches any document in the 'cities' collection or subcollections.
match /cities/{document=**} {
allow read, write: if true;
}
}
}
W powyższym przykładzie wszystkie odczyty i zapisy w kolekcji cities
będą dozwolone, ponieważ druga reguła jest zawsze true
, nawet jeśli pierwsza reguła jest zawsze false
.
Limity reguł bezpieczeństwa
Pracując z regułami bezpieczeństwa, zwróć uwagę na następujące ograniczenia:
Limit | Detale |
---|---|
Maksymalna liczba exists() , get() , a getAfter() zwraca na żądanie |
Przekroczenie któregokolwiek z limitów powoduje błąd odmowy uprawnień. Niektóre wywołania dostępu do dokumentów mogą być buforowane, a te z pamięci podręcznej nie wliczają się do limitów. |
Maksymalna głębokość instrukcji match zagnieżdżonego | 10 |
Maksymalna długość ścieżki w segmentach ścieżki dozwolona w zestawie zagnieżdżonych instrukcji match | 100 |
Maksymalna liczba zmiennych przechwytywania ścieżki dozwolonych w zestawie zagnieżdżonych instrukcji match | 20 |
Maksymalna głębokość wywołania funkcji | 20 |
Maksymalna liczba argumentów funkcji | 7 |
Maksymalna liczba powiązań zmiennej let na funkcję | 10 |
Maksymalna liczba rekurencyjnych lub cyklicznych wywołań funkcji | 0 (niedozwolone) |
Maksymalna liczba wyrażeń ocenianych na żądanie | 1000 |
Maksymalny rozmiar zestawu reguł | Zestawy reguł Verax muszą przestrzegać dwóch ograniczeń rozmiaru:
|
Magazyn w chmurze
Podstawowa struktura
Reguły zabezpieczeń Firebase w Cloud Firestore i Cloud Storage mają następującą strukturę i składnię:
service <<name>> {
// Match the resource path.
match <<path>> {
// Allow the request if the following conditions are true.
allow <<methods>> : if <<condition>>
}
}
Podczas tworzenia reguł należy zrozumieć następujące kluczowe pojęcia:
- Żądanie: metoda lub metody wywołane w instrukcji
allow
. To są metody, na które pozwalasz. Standardowe metody to:get
,list
,create
,update
idelete
. Doread
iwrite
metody wygoda umożliwić szeroki dostęp do odczytu i zapisu na określonej ścieżce bazy danych lub pamięci masowej. - Ścieżka: baza danych lub lokalizacja magazynu reprezentowana jako ścieżka identyfikatora URI.
- Reguła: instrukcja
allow
, która zawiera warunek, który zezwala na żądanie, jeśli zostanie oszacowane jako prawda.
Pasujące ścieżki
Reguły bezpieczeństwa Cloud Storage są match
ze ścieżkami plików używanymi do uzyskiwania dostępu do plików w Cloud Storage. Reguły mogą match
dokładne ścieżki lub ścieżki z symbolami wieloznacznymi, a reguły mogą być również zagnieżdżane. Jeśli żadna reguła dopasowania nie zezwala na metodę żądania lub warunek ma wartość false
, żądanie jest odrzucane.
Dokładne dopasowania
// Exact match for "images/profilePhoto.png" match /images/profilePhoto.png { allow write: if <condition>; } // Exact match for "images/croppedProfilePhoto.png" match /images/croppedProfilePhoto.png { allow write: if <other_condition>; }
Zagnieżdżone dopasowania
// Partial match for files that start with "images" match /images { // Exact match for "images/profilePhoto.png" match /profilePhoto.png { allow write: if <condition>; } // Exact match for "images/croppedProfilePhoto.png" match /croppedProfilePhoto.png { allow write: if <other_condition>; } }
Dopasowania wieloznaczne
Reguł można również używać do match
wzorca za pomocą symboli wieloznacznych. Symbol wieloznaczny to nazwana zmienna, która reprezentuje pojedynczy ciąg, taki jak profilePhoto.png
, lub wiele segmentów ścieżki, na przykład images/profilePhoto.png
.
Symbol wieloznaczny jest tworzony przez dodanie nawiasów klamrowych wokół nazwy symbolu wieloznacznego, na przykład {string}
. Wielosegmentowy symbol wieloznaczny można zadeklarować, dodając =**
do nazwy symbolu wieloznacznego, na przykład {path=**}
:
// Partial match for files that start with "images" match /images { // Exact match for "images/*" // e.g. images/profilePhoto.png is matched match /{imageId} { // This rule only matches a single path segment (*) // imageId is a string that contains the specific segment matched allow read: if <condition>; } // Exact match for "images/**" // e.g. images/users/user:12345/profilePhoto.png is matched // images/profilePhoto.png is also matched! match /{allImages=**} { // This rule matches one or more path segments (**) // allImages is a path that contains all segments matched allow read: if <other_condition>; } }
Jeśli do pliku pasuje wiele reguł, wynikiem jest OR
wyniku wszystkich ocen reguł. Oznacza to, że jeśli jakakolwiek reguła, do której pasuje plik, evaluje na true
, wynik jest true
.
W powyższych zasadach plik „images / profilePhoto.png” można odczytać, jeśli condition
lub other_condition
wartość true, podczas gdy plik „images / users / user: 12345 / profilePhoto.png” podlega tylko wynikowi other_condition
.
Do zmiennej wieloznacznej można się odwołać z poziomu match
podaj nazwę pliku lub ścieżkę autoryzacji:
// Another way to restrict the name of a file match /images/{imageId} { allow read: if imageId == "profilePhoto.png"; }
Reguły bezpieczeństwa Cloud Storage nie są kaskadowe, a reguły są oceniane tylko wtedy, gdy ścieżka żądania jest zgodna ze ścieżką z określonymi regułami.
Poproś o ocenę
Przesłane, pobrane pliki, zmiany metadanych i usunięcia są oceniane na podstawie request
wysłanego do Cloud Storage. Zmienna request
zawiera ścieżkę do pliku, w którym żądanie jest wykonywane, czas odebrania żądania i nową wartość resource
jeśli żądanie jest zapisem. Uwzględniane są również nagłówki HTTP i stan uwierzytelniania.
Obiekt request
zawiera również unikatowy identyfikator użytkownika i ładunek uwierzytelniania Firebase w obiekcie request.auth
, co zostanie wyjaśnione bardziej szczegółowo w sekcji Uwierzytelnianie w dokumentacji.
Pełna lista właściwości w obiekcie request
jest dostępna poniżej:
własność | Rodzaj | Opis |
---|---|---|
auth | map <string, string> | Gdy użytkownik jest zalogowany, dostarcza uid , unikalny identyfikator użytkownika i token , mapę oświadczeń token JWT uwierzytelniania Firebase. W przeciwnym razie będzie null . |
params | map <string, string> | Mapa zawierająca parametry zapytania żądania. |
path | ścieżka | path reprezentująca ścieżkę, na której jest wykonywane żądanie. |
resource | map <string, string> | Nowa wartość zasobu, obecna tylko w żądaniach write . |
time | znak czasu | Sygnatura czasowa reprezentująca czas serwera, w którym żądanie jest oceniane. |
Ocena zasobów
Oceniając reguły, możesz również chcieć ocenić metadane przesyłanego, pobieranego, modyfikowanego lub usuwanego pliku. Pozwala to na tworzenie złożonych i potężnych reguł, które wykonują takie czynności, jak zezwalanie na przesyłanie tylko plików z określonymi typami zawartości lub usuwanie tylko plików większych niż określony rozmiar.
Reguły bezpieczeństwa Firebase dla Cloud Storage zapewniają metadane plików w obiekcie resource
, które zawierają pary klucz / wartość metadanych pojawiających się w obiekcie Cloud Storage. Te właściwości można sprawdzać w żądaniach read
lub write
aby zapewnić integralność danych.
W przypadku żądań write
(takich jak przesyłanie, aktualizowanie i usuwanie metadanych), oprócz obiektu resource
, który zawiera metadane pliku dla pliku, który obecnie istnieje na ścieżce żądania, masz również możliwość korzystania z obiektu request.resource
, który zawiera podzbiór metadanych pliku do zapisania, jeśli zapis jest dozwolony. Możesz użyć tych dwóch wartości, aby zapewnić integralność danych lub wymusić ograniczenia aplikacji, takie jak typ lub rozmiar pliku.
Pełna lista właściwości w obiekcie resource
jest dostępna poniżej:
własność | Rodzaj | Opis |
---|---|---|
name | strunowy | Pełna nazwa obiektu |
bucket | strunowy | Nazwa zasobnika, w którym znajduje się ten obiekt. |
generation | int | Generowanie tego obiektu w Google Cloud Storage . |
metageneration | int | Metageneracja tego obiektu w Google Cloud Storage . |
size | int | Rozmiar obiektu w bajtach. |
timeCreated | znak czasu | Sygnatura czasowa reprezentująca czas utworzenia obiektu. |
updated | znak czasu | Sygnatura czasowa reprezentująca czas ostatniej aktualizacji obiektu. |
md5Hash | strunowy | Skrót MD5 obiektu. |
crc32c | strunowy | Skrót crc32c obiektu. |
etag | strunowy | Etag powiązany z tym obiektem. |
contentDisposition | strunowy | Dyspozycja treści skojarzona z tym obiektem. |
contentEncoding | strunowy | Kodowanie treści skojarzone z tym obiektem. |
contentLanguage | strunowy | Język treści powiązany z tym obiektem. |
contentType | strunowy | Typ zawartości powiązany z tym obiektem. |
metadata | map <string, string> | Pary klucz / wartość dodatkowych niestandardowych metadanych określonych przez programistę. |
request.resource
zawiera wszystkie te elementy z wyjątkiem generation
, metageneration
, etag
, timeCreated
i updated
.
Pełny przykład
Podsumowując, możesz stworzyć pełny przykład reguł dla rozwiązania do przechowywania obrazów:
service firebase.storage { match /b/{bucket}/o { match /images { // Cascade read to any image type at any path match /{allImages=**} { allow read; } // Allow write files to the path "images/*", subject to the constraints: // 1) File is less than 5MB // 2) Content type is an image // 3) Uploaded content type matches existing content type // 4) File name (stored in imageId wildcard variable) is less than 32 characters match /{imageId} { allow write: if request.resource.size < 5 * 1024 * 1024 && request.resource.contentType.matches('image/.*') && request.resource.contentType == resource.contentType && imageId.size() < 32 } } } }
Baza danych czasu rzeczywistego
Podstawowa struktura
W bazie danych czasu rzeczywistego reguły zabezpieczeń Firebase składają się z wyrażeń podobnych do JavaScript zawartych w dokumencie JSON.
Używają następującej składni:
{
"rules": {
"<<path>>": {
// Allow the request if the condition for each method is true.
".read": <<condition>>,
".write": <<condition>>,
".validate": <<condition>>
}
}
}
Reguła składa się z trzech podstawowych elementów:
- Ścieżka: lokalizacja bazy danych. Odzwierciedla to strukturę JSON Twojej bazy danych.
- Żądanie: są to metody używane przez regułę do udzielania dostępu. Reguły
read
iwrite
zapewniają szeroki dostęp do odczytu i zapisu, podczas gdy regułyvalidate
działają jako wtórna weryfikacja w celu przyznania dostępu na podstawie przychodzących lub istniejących danych. - Warunek: warunek, który zezwala na żądanie, jeśli zostanie ocenione jako prawda.
Jak zasady odnoszą się do ścieżek
W bazie danych czasu rzeczywistego reguły są stosowane niepodzielnie, co oznacza, że reguły w węzłach nadrzędnych wyższego poziomu zastępują reguły w bardziej szczegółowych węzłach podrzędnych, a reguły w węźle głębszym nie mogą udzielać dostępu do ścieżki nadrzędnej. Nie możesz zawęzić ani cofnąć dostępu na głębszej ścieżce w strukturze bazy danych, jeśli został już przyznany dla jednej ze ścieżek nadrzędnych.
Rozważ następujące zasady:
{ "rules": { "foo": { // allows read to /foo/* ".read": "data.child('baz').val() === true", "bar": { // ignored, since read was allowed already ".read": false } } } }
Ta struktura bezpieczeństwa umożliwia odczytanie /bar/
zawsze, gdy /foo/
zawiera potomny baz
o wartości true
. ".read": false
w /foo/bar/
nie ma tu żadnego efektu, ponieważ dostępu nie można cofnąć ścieżką podrzędną.
Chociaż od razu nie wydaje się to intuicyjne, jest to potężna część języka reguł i pozwala na implementację bardzo złożonych uprawnień dostępu przy minimalnym wysiłku. Jest to szczególnie przydatne w przypadku zabezpieczeń opartych na użytkownikach .
Jednak reguły .validate
nie są kaskadowe. Aby zapis był dozwolony, wszystkie reguły walidacji muszą być spełnione na wszystkich poziomach hierarchii.
Ponadto, ponieważ reguły nie mają zastosowania z powrotem do ścieżki nadrzędnej, operacja odczytu lub zapisu kończy się niepowodzeniem, jeśli nie ma reguły w żądanej lokalizacji lub w lokalizacji nadrzędnej, która przyznaje dostęp. Nawet jeśli każda ścieżka podrzędna, której dotyczy problem, jest dostępna, odczyt w lokalizacji nadrzędnej całkowicie się nie powiedzie. Rozważ tę strukturę:
{ "rules": { "records": { "rec1": { ".read": true }, "rec2": { ".read": false } } } }
Bez zrozumienia, że reguły są oceniane niepodzielnie, może się wydawać, że rec1
/records/
path rec1
ale nie rec2
. Rzeczywisty wynik jest jednak błędem:
JavaScript
var db = firebase.database(); db.ref("records").once("value", function(snap) { // success method is not called }, function(err) { // error callback triggered with PERMISSION_DENIED });
Cel C
FIRDatabaseReference *ref = [[FIRDatabase database] reference]; [[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) { // success block is not called } withCancelBlock:^(NSError * _Nonnull error) { // cancel block triggered with PERMISSION_DENIED }];
Szybki
var ref = FIRDatabase.database().reference() ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in // success block is not called }, withCancelBlock: { error in // cancel block triggered with PERMISSION_DENIED })
Jawa
FirebaseDatabase database = FirebaseDatabase.getInstance(); DatabaseReference ref = database.getReference("records"); ref.addListenerForSingleValueEvent(new ValueEventListener() { @Override public void onDataChange(DataSnapshot snapshot) { // success method is not called } @Override public void onCancelled(FirebaseError firebaseError) { // error callback triggered with PERMISSION_DENIED }); });
ODPOCZYNEK
curl https://docs-examples.firebaseio.com/rest/records/ # response returns a PERMISSION_DENIED error
Ponieważ operacja odczytu w /records/
jest atomowa i nie ma reguły odczytu, która przyznaje dostęp do wszystkich danych w /records/
, spowoduje to błąd PERMISSION_DENIED
. Jeśli ocenimy tę regułę w symulatorze bezpieczeństwa w naszej konsoli Firebase , zobaczymy, że operacja odczytu została odrzucona:
Attempt to read /records with auth=Success(null) / /records No .read rule allowed the operation. Read was denied.
Operacja została odrzucona, ponieważ żadna reguła odczytu nie zezwalała na dostęp do /records/
path, ale pamiętaj, że reguła dla rec1
nigdy nie została oceniona, ponieważ nie znajdowała się w żądanej ścieżce. Aby pobrać rec1
, musielibyśmy uzyskać do niego bezpośredni dostęp:
JavaScript
var db = firebase.database(); db.ref("records/rec1").once("value", function(snap) { // SUCCESS! }, function(err) { // error callback is not called });
Cel C
FIRDatabaseReference *ref = [[FIRDatabase database] reference]; [[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) { // SUCCESS! }];
Szybki
var ref = FIRDatabase.database().reference() ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in // SUCCESS! })
Jawa
FirebaseDatabase database = FirebaseDatabase.getInstance(); DatabaseReference ref = database.getReference("records/rec1"); ref.addListenerForSingleValueEvent(new ValueEventListener() { @Override public void onDataChange(DataSnapshot snapshot) { // SUCCESS! } @Override public void onCancelled(FirebaseError firebaseError) { // error callback is not called } });
ODPOCZYNEK
curl https://docs-examples.firebaseio.com/rest/records/rec1 # SUCCESS!
Zmienna lokalizacji
Reguły bazy danych czasu rzeczywistego obsługują zmienną $location
celu dopasowania segmentów ścieżki. Użyj przedrostka $
przed segmentem ścieżki, aby dopasować regułę do wszystkich węzłów podrzędnych na ścieżce.
{
"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')"
}
}
}
}
}
Możesz również użyć $variable
równolegle z nazwami stałych ścieżek.
{
"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 }
}
}
}