Правильные правила авторизации для защищенного контента в firebase
есть ли наилучший подход к правилам авторизации для защищенного контента в приложении firebase
- использование firepad специально
- по защищенным контентом я имею в виду, когда пользователь создает документ и передает его с некоторыми другими пользователями).
- также мне нужно иметь возможность запрашивать firebase для всех документов, к которым у меня есть доступ (документы, которые я создал, и документы, которыми поделились со мной другие пользователи)
некоторые из мои исследования до сих пор:
метод 1: секретный URL
мне нужно знать URL, чтобы иметь возможность просматривать / редактировать документ
не реальная авторизация, так как любой зарегистрированный пользователь, имеющий доступ к этому URL, может редактировать/изменять его.
не могу индексировать все документы, к которым у меня есть доступ
Способ 2: использование правил авторизации firebase для добавления пользователей в документ и проверьте, является ли пользователь документом.пользователи перед чтением / записью.
Взяты Из: защищенный контент в Firebase возможен?
{
"documents": {
"$documents_id": {
// any friend can read my post
".read": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()",
// any friend can edit my post
".write": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()"
},
users:{
// List of user.ids that have access to this document
}
}
}
плюсы:
- правильная авторизация / аутентификация. Просматривать/редактировать могут только прошедшие проверку подлинности пользователи, которым был предоставлен доступ.
плюсы:
- Не удается запросить все документы, которые пользователь может редактировать (те, которые у меня есть или были совместно со мной) (это предположение правильно?)
Способ 3: правила авторизации Firebase (Метод 2), плюс избыточное хранилище пользователей с массивом document_ids, к которому каждый пользователь имеет доступ. Это хранилище пользователей будет использоваться только для запроса всех документов, к которым пользователь имеет доступ. т. е.:
{
"documents": {
"$documents_id": {
// any friend can read my post
".read": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()",
// any friend can edit my post
".write": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()"
}
},
"users":{
"$user":{
".read": "auth.id=$user.id",
".write": "auth.id=$user.id"
"$documents":{
// All the documents i have access to. This list gets ammended whenever I am granted/stripped access to a document.
}
}
}
}
плюсы:
- аутентификации/авторизации
плюсы:
- дублировать данные, иметь дело с проблемами синхронизации между два хранилища данных. Это просто не кажется хорошей идеей.
Метод 4: Группы
использование групп в предоставление доступа к местоположениям Firebase группе пользователей
у нас есть группа для каждого документа в хранилище данных
Не могу легко запросить firebase для всех документов, к которым пользователь может получить доступ
есть ли лучший способ сделать это?
1 ответов
вы проделали хорошую работу по перечислению вариантов, и вы определенно на правильном пути. Как вы обнаружили, нет возможности запрашивать на основе правил безопасности. Это было сделано намеренно, так как (в зависимости от ваших правил безопасности) это может быть довольно дорого (Firebase избегает сложных запросов вообще по этой причине).
таким образом, ваш метод 3-это правильный способ сделать это. Дублирование данных для таких ситуаций на самом деле является очень распространенной практикой. Видеть денормализация ваших данных является нормальной для сообщения в блоге, которое более подробно об этом.
вы также можете сделать метод 1 с дублированным списком документов. Это особенно полезно, если вы хотите иметь возможность "пригласить" кого-то в документ только с URL-адресом (который содержит секретный идентификатор). Или вы можете сделать комбинацию из двух (некоторые документы должны быть "публичными, но не включенными в список", а некоторые - "частными для приглашенных друзей" или что-то еще.)