Firebase Организация членства в документе
Я создаю приложение в Firebase, которое должно гарантировать, что пользователи могут читать/записывать только документы/коллекции, принадлежащие их команде. Мой вопрос в основном заключается в том, как мне структурировать данные о членстве. В частности, вот одна идея, которую я рассматривал:
/teams/{teamid}
{
displayName: "Company X Team",
owner: "userid",
members: ["email1", "email2", "email3"]
}
/teams/{teamid}/projects/{projectid}
{
name: "My Project"
otherProps: "Other Properties"
}
/users/{userid}
{
displayName: "John Doe",
email: "[email protected]"
}
Должен ли я хранить «участников» в виде массива в составе документа /teams/ (как показано в приведенном выше примере кода)? Или я должен хранить его как собственную коллекцию документов, как и /projects/?
Меня больше всего беспокоит, когда я иду и пишу правила безопасности. Я хочу убедиться, что только владелец или участники могут вносить изменения в /teams/ и его подколлекции (например: /projects/).
Для какого способа будет проще написать правила безопасности? Какой из них будет иметь лучшую производительность?
Это очень верно. Я формулировал запрос, когда решил задать этот вопрос. В частности, мне нужен запрос, который будет искать /teams/ и сообщать мне, был ли приглашен авторизованный пользователь.
Ответы 1
Я бы структурировал элементы как подколлекцию, а не как массив. Сделайте идентификатор документа каждого члена подколлекции идентификатором пользователя.
Затем вы можете просто написать простое правило безопасности exists(). Это также позволит вам хранить дополнительные данные о членстве (являются ли некоторые участники администраторами, когда они присоединились и т. д.).
match /teams/{teamid}/projects/{projectid} {
// Make sure a 'user' is a member of the team
allow write: if exists(/databases/$(database)/documents/teams/${teamid}/members/$(request.auth.uid))
}
https://firebase.google.com/docs/firestore/security/rules-conditions#access_other_documents
Мне нравится это. Однако теперь, когда я думаю об этом, возможно, я сделаю и то, и другое. Я буду хранить массив в документе /teams/, называть его «Приглашения» и хранить адреса электронной почты. У меня не будет «uid», пока человек не пройдет аутентификацию в первый раз. Это означает, что мне нужно правило, которое говорит что-то вроде: «Вы не можете добавить себя в /members/, если ваш auth.email не указан в приглашениях. Это звучит разумно?
@ScottDietrich, это звучит разумно. Другой подход к хранению электронной почты — создать еще одну подколлекцию с именем «email_invites», где каждый идентификатор документа является адресом электронной почты. Мне этот подход нравится немного больше, потому что так проще добавлять/удалять приглашения. Кроме того, если вы хотите, чтобы некоторые метаданные были прикреплены к каждому приглашению по электронной почте (например, дата истечения срока действия), это было бы проще сделать, если бы каждое электронное приглашение было документом.
Прежде чем структурировать данные, вам нужно подумать о том, как вы собираетесь запрашивать данные. Это самое главное. Не зная сначала запросов, структура может быть проблематичной в будущем.