Это было очень трудно для меня, чтобы понять, чтобы начать с, но правила очень гибкие и позволяют вам базовый доступ к данным на основе другого содержимого базы данных. В основном вы предоставляете доступ к узлу, и этот грант применяется ко всем дочерним элементам и не может быть удален из более глубоких узлов в дереве. Вы можете применить эти правила базы данных в консоли, но должен быть api, если вам нужно также использовать его, чтобы установить правила для всей базы данных. Они должны быть единым документом, поэтому вы не захотите жестко программировать пользователей, но вы можете поместить их в скрытый и недоступный узел, правила имеют к нему доступ.
Например, предположим, что вы хотите, чтобы люди просили дружить с другими людьми, а другой человек мог принять и добавить обоих людей в список друзей. Вы могли бы иметь схему, подобную этой:
uid
"friends"
friendUid1
friendUid2
friendUid3
"private"
... some private data your friends can read
"friendRequests"
targetUid
requestorUid -> can be written to only by requestorUid
Первый шаг пишущего значение friendRequests/$targetUid/$requestorUid. ТОЛЬКО человек, который может писать на этот узел, является тем, который аутентифицирован как requestorUid. targetUid получит доступ для чтения к узлу targetUid, чтобы он мог его прочитать, потому что он является дочерним, но не записывает его.
Тогда вы можете предоставить доступ для записи к $requestor/friends/$targetUid в $ targetUid на основе наличия friendRequests/targetUid/requestorUid. Это позволяет человеку, который получил запрос друга, написать свой СОБСТВЕННЫЙ uid в список друзей запрашивающего, но только если проситель уже написал свой собственный uid в запросе, чтобы стать другом. Затем они пишут запросчика в свой список друзей. Если uid зарегистрированного пользователя находится в списке своих друзей, они могут получить доступ к личным данным.
{
"rules": {
"$uid": {
".read": "auth.uid === $uid",
".write": "auth.uid === $uid",
"friends": {
"$friendId": {
".write": "root.child('friendRequests').child($friendId).child($uid) && auth.uid === $friendId"
}
},
"private": {
".read": "data.parent().child('friends').child(auth.uid).exists()"
}
},
"friendRequests": {
"$targetUid": {
".read": "auth.uid === $targetUid",
"$requestorUid": {
".write": "auth.uid === $requestorUid"
}
}
}
}
}
Давайте использовать некоторые «реальные» иды и сказать, что UID 100 хочет быть друзьями с идентификаторами 200. Они пишут свой собственный идентификатор 100 будет запрос на 200, это разрешено, потому что auth.uid будет соответствовать $ requestorUid и соответствовать последнему правилу записи:
ref = db.getReference("friendRequests/200/100");
ref.setValue(true);
Когда идентификатор пользователя 200 входит в, они могут прочитать все свои запросы друга на friendRequests/200. Они видят, что пользователь 100 просил быть их другом, поэтому они сначала добавляют 100 к users/200/friends. Это разрешено, поскольку auth.uid будет 200, и у них есть полный доступ для чтения/записи для всего узла users/200 и всех его дочерних элементов.
Далее они также могут написать users/100/friends/200, потому что это правило:
"root.child('friendRequests').child($friendId).child($uid) && auth.uid === $friendId"
auth.uid будет 200 и чек будет видеть, что 100 попросил, чтобы стать друзьями с 200, потому что friendRequests/200/100 существует и что узел доступен для записи только пользователем 100.
Модель безопасности для базы данных Firebase обсуждается в документации: https://firebase.google.com/docs/database/security/. Он применяется на серверах Firebase, поэтому он не специфичен для вашего клиента iOS. Я рекомендую вам изучить документацию, попытаться заставить ее работать для вашего прецедента и вернуться сюда, если у вас возникла проблема с реализацией правил. –