2013-07-22 10 views
24

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ć?

Odpowiedz

12

Zrobiłeś dobrą robotę wyliczając opcje i jesteś zdecydowanie na dobrej drodze. Jak już odkryłeś, nie ma możliwości wysyłania zapytań na podstawie reguł bezpieczeństwa. Zostało to zrobione celowo, ponieważ (w zależności od twoich zasad bezpieczeństwa) może to być dość kosztowne (Firebase unika generalnie złożonych zapytań z tego powodu).

Twoja metoda 3 jest dokładnie taka, jak to możliwe. Powielanie danych dla tego rodzaju sytuacji jest w rzeczywistości bardzo powszechną praktyką. Zajrzyj do Denormalizing Your Data is Normal dla wpisu na blogu, który zawiera więcej szczegółów na ten temat.

Można również wykonać metodę 1 ze zduplikowaną listą dokumentów. Jest to szczególnie przydatne, jeśli chcesz "zaprosić" kogoś do dokumentu za pomocą adresu URL (który zawiera tajny identyfikator). Lub możesz zrobić kombinację tych dwóch elementów (niektóre dokumenty mogą być "publiczne, ale niepubliczne", a niektóre "prywatne dla zaproszonych znajomych" lub inne).

+0

Dziękuję Michaelowi za to wyjaśnienie. Po prostu trzeba zachować ostrożność, zachowując ważne bity od każdego z nich. – abaker

+1

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%. :-) –