Правила Firestore: Как разрешить конкретное c редактирование чужой записи? - PullRequest
Новая
       0

Правила Firestore: Как разрешить конкретное c редактирование чужой записи?

0 голосов
/ 27 февраля 2020

У меня есть приложение с пользователями и заданиями.

Каждое задание принадлежит одному пользователю. Только этот Пользователь может редактировать задание.

Любой пользователь может подать заявку на любое задание. Когда пользователь применяет к заданию, я хочу добавить этого пользователя в массив job.appliedCandidates. В основном структура выглядит так: 

Jobs
    - Job1
        - owner = User1
        - candidatesApplied
            - User2
            - User3

Таким образом, User1 владеет Job1. Допустим, User4 приходит и применяется к работе. Теперь я хочу добавить его к candidatesApplied. Но у него нет прав на редактирование этой работы, потому что он не является владельцем!

И если я дам ему доступ для редактирования, он сможет изменить все данные работы. Не то, что я хочу.

Я уверен, что в Firestore вы можете создавать правила для каждого поля, но это все равно не решает мою проблему. Если User4 может редактировать job1.candidatesApplied, это означает, что у него есть доступ к удалению других пользователей из массива!

Я почти уверен, что настройка массива, которую я собираюсь выполнить, не подходит для go , Одна идея состоит в том, чтобы «кандидаты» были вложенной коллекцией задания и позволяли любому пользователю создавать запись в этой вложенной коллекции, но не делать ничего другого. Но я не уверен, что это правильно.

Как лучше всего справиться с этим?

1 Ответ

1 голос
/ 27 февраля 2020

Учитывая, что вы не установили ограничения на количество претендентов на работу, давайте просто предположим, что список кандидатов может значительно увеличиться. Если это так, то даже моделирование этих данных в виде списка в одном документе подвержено ошибкам, поскольку для документа существует отдельный максимальный размер: 1 МБ. И мы пока даже не говорим о безопасности.

Чтобы избежать проблемы максимального размера документа, лучший способ решить эту проблему - поместить каждого кандидата в свой собственный документ. Независимо от того, является ли это коллекция или подколлекция, в основном не имеет значения.

Если вы решили сохранить каждого кандидата в качестве документа в коллекции, теперь вы не ограничены каким-либо произвольным максимумом кандидатов, и легче писать правила для этого. То, какими должны быть эти правила, выходит за рамки того, что вы предложили здесь до сих пор. Но гибкое моделирование данных позволяет предположить, что подход к подколлекциям менее подвержен проблемам.

...