Czy istnieje podejście najlepsze praktyki do odpowiednich zasad wydawania zezwoleń na zawartość chronioną w Firebase aplikacjiOdpowiednie zasady wydawania zezwoleń na treści chronione w Firebase
- użyciu firepad specjalnie
- Dzięki zawartości chronionej Znaczy gdzie użytkownik tworzy dokument i udostępnia go tylko niektórym innym użytkownikom).
- także muszę być w stanie kwerendy Firebase do wszystkich dokumentów, które mam dostęp do (docs, że stworzył i docs inni użytkownicy wspólnych ze mną)
Niektóre z moich badań do tej pory:
Metoda 1: Tajny URL
muszę znać adres URL, aby móc przeglądać/edytować dokument
Nieautentyczna autoryzacja, ponieważ każdy zalogowany użytkownik mający dostęp do tego adresu URL może edytować/modyfikować.
Cant spis wszystkich docs mam dostęp do
Metoda 2: Korzystanie Firebase reguł autoryzacji, aby dodać użytkowników do dokumentu i sprawdzić, czy użytkownik jest document.users przed zapisu/odczytu.
Taken From: Protected content in Firebase possible?
{
"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
}
}
}
Plusy:
- odpowiedniej autoryzacji/uwierzytelnienia. Tylko uwierzytelnieni użytkownicy, którym przyznano dostęp, mogą wyświetlać/edytować.
Wady:
- nie może zapytać o wszystkich dokumentach użytkownik może edytować (tych, które ja właścicielem lub zostały udostępnione ze mną) (? Czy to założenie poprawne)
Metoda 3: Reguły autoryzacji Firebase (metoda 2) oraz nadmiarowy magazyn użytkowników z tablicą id_dokumentów, do których mają dostęp każdy użytkownik. Ten magazyn użytkownika będzie używany tylko do wysyłania zapytań do wszystkich dokumentów, do których użytkownik ma dostęp. tj:
{
"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.
}
}
}
}
Plusy:
- Właściwa uwierzytelniania/autoryzacji
Wady:
- duplikatów danych, mają do czynienia z problemami synchronizacji pomiędzy dwoma zbiorami danych. To po prostu nie wygląda na dobry pomysł.
Metoda 4: Grupy
Korzystanie z grup za Granting access to Firebase locations to a group of users
Mamy grupę dla każdego dokumentu w magazynie danych
Cant łatwo kwerendy Firebase dla wszystkich docs użytkownik może uzyskać dostęp do
Czy jest lepszy sposób to zrobić?
Dziękuję Michaelowi za to wyjaśnienie. Po prostu trzeba zachować ostrożność, zachowując ważne bity od każdego z nich. – abaker
Tak. Chociaż w wielu przypadkach można dość łatwo uczynić swój kod odpornym na niedopasowania. Na przykład, jeśli na liście znajduje się dokument, ale podczas próby odczytu jego metadanych pojawia się błąd odmowy uprawnień, po prostu ukryj go przed użytkownikiem. W ten sposób reguły bezpieczeństwa są Prawdziwymi Autorytetami, a twoja lista osobistych dokumentów jest tylko "podpowiedzią", do czego powinieneś mieć dostęp, a jeśli stanie się trochę niezsynchronizowana, to nie ma znaczenia. Oczywiście, jeśli możesz zapewnić ich synchronizację, to lepiej, ale nie zawsze jest to konieczne w 100%. :-) –