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;
}
}

}
}
730   2  

2 ответов:

Проблема, с которой вы столкнулись, вызвана тем, что "правила безопасности не являются фильтрами ", см. Этот документпункт .

Другими словами, ваш запрос должен фильтровать организации, для которых пользователь имеет права доступа (чтения), например, как вы делаете с "массивом в документе, который содержит список usersids". Вы также можете иметь списки организаций в виде массива в пользовательском документе doc.

Использование облачной функции для "проверки листинга на стороне сервера" и (если я поймите правильно) построить свой запрос на основе результата этого вызова облачной функции действительно не идеально.

Но то, что вы можете сделать с облачной функцией, - это автоматически заполнить/изменить массив, содержащий userids (или organizations), Когда вы создаете/изменяете/удаляете документ organisationid под users/userid/ar/organisationid.
Обратите внимание, что док говорит:

Это поведение применимо к запросам, которые извлекают один или несколько документов от коллекции , а не к отдельному документу retrievals

Вот почему ваши правила работают для метода get(), Как вы упомянули.

См. документацию

Управление доступом с помощью пользовательских утверждений и правил безопасности

Пакет Firebase Admin SDK поддерживает определение пользовательских атрибутов для пользователя счета. Это обеспечивает возможность реализации различного доступа стратегии управления, включая управление доступом на основе ролей, в Firebase приложения. Эти пользовательские атрибуты могут предоставлять пользователям различные уровни доступ (роли), которые применяются в правилах безопасности приложения.

Comments

    Ничего не найдено.