2011-01-19 16 views

Odpowiedz

22

Tak, CouchDB może zapobiegać nieautoryzowanym odczytom. Niestety jest to nieco mniej proste.

Wyobraź sobie tajną aplikację aukcyjną. Cena 20 USD, a ja 10 USD; każda oferta w dokumencie na kanapę. Leżanka pozwala nam czytać nasze własne dokumenty ofertowe, ale żadnych innych. Jednak istnieje, jest mapa zmniejsz widok pokazujący średnią. Załaduję widok i widzę, że średnia wynosi 15 USD, więc stwierdzam, że twoja oferta wynosi 20 USD i złamałem zasady bezpieczeństwa. Wyświetl dane wyjściowe mogą wyciec niektóre lub wszystkie informacje dokumentu. Nie jest możliwe egzekwowanie zabezpieczeń na poziomie dokumentu. Dlatego dostęp do odczytu jest na poziomie bazy danych.

Wiem, to jest do bani. Ale to jedyna poprawna, skalowalna odpowiedź.

Jest to jeden z powodów, dla których filozofia kanapki polega na tworzeniu wielu baz danych na poziomie nawet jednego (lub więcej!) Na użytkownika. Uprawnienia odczytu do bazy danych są ustawiane w wartości readers obiektu bazy danych _security. (Uwaga, pola readers was renamed to members w couchdb bagażniku, ponieważ również określa, kto może napisać do DB.)

Technika działa tak:

  1. Tworzenie bazy danych dla każdego użytkownika. Będzie zawierał wszystkie dokumenty, które może przeczytać użytkownik. Dodaj użytkownika (lub rolę użytkownika) do obiektu _security.
  2. W głównej bazie danych utwórz funkcję filtrującą, która implementuje politykę odczytu. (Może on współdzielić kod z validate_doc_update.)
  3. Replikacja z głównej bazy danych do bazy danych użytkownika za pomocą ?filter=my_filter_function.
  4. Umożliwia użytkownikowi załadowanie (lub skopiowanie) z ich bazy danych.

Oczywiście wszystko to dotyczy aplikacji w czystej kanapy, w której użytkownicy mają bezpośredni dostęp do kanapki. Jeśli masz warstwę środkową (kontroler MVC lub tylko odwrotny serwer proxy HTTP), możesz wymusić na niej politykę, między użytkownikiem a kanapą. Ale należy zachować ostrożność. Na przykład funkcja _show lub reguła _rewrite może umożliwić użytkownikowi załadowanie widoku lub dokumentu pomimo zasad.

Powodzenia!

+0

Dzięki! Czy mógłbyś wyjaśnić, jak _show i _rewrite mogą mnie ugryźć? Ponadto, w jaki sposób uniknąć sytuacji wyścigowych, takich jak "unfriend someone -> upload photo" i będąc w 100% pewny, że nieprzyjazna osoba nigdy nie zobaczy tego zdjęcia? – nornagon

+0

Załóżmy, że masz odwrotny serwer proxy, który pozwala/odmawia dostępu dla każdego dokumentu na użytkownika na podstawie adresu URL. Później dodajesz nową funkcję za pomocą funkcji _list, a wszystkie zapytania _list są dozwolone przez serwer proxy. Użytkownik może dowiedzieć się, jak korzystać z _list, aby zobaczyć dokumenty, których nie powinien. Podobnie reguła _rewrite może zapewnić sposób wyświetlania dokumentów bez normalnej ścieżki '/ db/doc_id'. Więc musisz być * bardzo * pewny, że twój serwer proxy nie ma dziur. – JasonSmith

+2

Twoje drugie pytanie dotyczy raczej ** odwołania ** dostępu do odczytu niż ** udzielenia ** dostępu do odczytu. Proponuję zadać nowe pytanie ("Jak odwołać dostęp do odczytu w modelu bezpieczeństwa CouchDB"). Postaram się odpowiedzieć, jeśli potrafię! – JasonSmith