Firestore правила организации мульти мульти прав доступа пользователей список данных
Я пытаюсь настроить набор правил для нового проекта Firestore, в котором у нас есть следующие корневые коллекции:
Пользователи
Организации
В разделе Пользователи есть Пользователи/Имя пользователя/АР/organisationid (Арканзас по правам доступа)
Этот документ должен определять, какие права доступа пользователь имеет для данной организации. Дело в том, что многие пользователи могут иметь доступ к одной или нескольким организациям в этом приложении saas.
Мне нужны все документы и вся информация. подколлекции в рамках проверяемой организации имеют это право доступа.
Это прекрасно работает для get и write, но перечисление данных дает ошибку доступа, и единственный способ, который я нашел, чтобы ограничить данные списка, - это добавить массив в документ, который перечисляет usersid, а также фильтровать на этой стороне клиента. Это не решение, которое может быть поддержано для производства, так как будет много вложенных коллекций со многими документами.
Есть ли какие-либо предложения? Любой другой способ я могу сделать список работающим для Firestore? Есть ли лучший способ структурировать данные или что - то, что я упустил?
Единственный другой способ, который я вижу, - это использовать функции firestore для проверки серверной части списка, но затем мы теряем удивительные вещи в @angular/fire.
Фильтрация на стороне клиента недостаточно надежна.
Спасибо.
Правила На данный момент:
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth.uid == userId;
match /ar/{organisationDoc} {
allow read: if request.auth.uid == userId;
allow write: if false;
}
}
// read
match /organisations/{oId} {
allow get: if exists(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId));
allow list: if request.auth.uid in resource.data.users;
match /{all=**} {
allow get: if exists(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId));
allow list: if request.auth.uid in resource.data.users;
}
}
// write
match /organisations/{oId} {
allow create: if get(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId)).data.create == true;
allow update: if get(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId)).data.update == true;
allow delete: if get(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId)).data.delete == true;
match /{all=**} {
allow create: if get(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId)).data.create == true;
allow update: if get(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId)).data.update == true;
allow delete: if get(/databases/$(database)/documents/users/$(request.auth.uid)/ar/$(oId)).data.delete == true;
}
}
}
}
2 ответов:
Проблема, с которой вы столкнулись, вызвана тем, что "правила безопасности не являются фильтрами ", см. Этот документпункт .
Другими словами, ваш запрос должен фильтровать организации, для которых пользователь имеет права доступа (чтения), например, как вы делаете с "массивом в документе, который содержит списокusersids". Вы также можете иметь списки организаций в виде массива в пользовательском документе doc.Использование облачной функции для "проверки листинга на стороне сервера" и (если я поймите правильно) построить свой запрос на основе результата этого вызова облачной функции действительно не идеально.
Но то, что вы можете сделать с облачной функцией, - это автоматически заполнить/изменить массив, содержащийuserids(илиorganizations), Когда вы создаете/изменяете/удаляете документorganisationidподusers/userid/ar/organisationid.
Обратите внимание, что док говорит:Вот почему ваши правила работают для методаЭто поведение применимо к запросам, которые извлекают один или несколько документов от коллекции , а не к отдельному документу retrievals
get(), Как вы упомянули.
Управление доступом с помощью пользовательских утверждений и правил безопасности
Пакет Firebase Admin SDK поддерживает определение пользовательских атрибутов для пользователя счета. Это обеспечивает возможность реализации различного доступа стратегии управления, включая управление доступом на основе ролей, в Firebase приложения. Эти пользовательские атрибуты могут предоставлять пользователям различные уровни доступ (роли), которые применяются в правилах безопасности приложения.
Comments