Ограничение доступа к ресурсам в CouchDB ровно двум пользователям - PullRequest
2 голосов
/ 05 ноября 2010

В настоящее время я нахожусь в процессе оценки CouchDB для нового проекта.

Ключевым ограничением для этого проекта является строгая конфиденциальность. Должны быть ресурсы, которые могут прочитать только два пользователя.

Один вариант использования может быть чем-то похожим на Прямые сообщения (DM) в Twitter. Другой вариант использования - уровень доступа Пользователь / Суперпользователь.

В настоящее время у меня нет идей о том, как решить подобные проблемы с CouchDB, кроме создания одной базы данных, доступной только этим двум пользователям. Интересно, как мне тогда строить представления, объединяющие данные из нескольких баз данных?

Есть ли у вас какие-либо подсказки / предложения для меня?

Ответы [ 2 ]

3 голосов
/ 12 ноября 2010

Я задавал этот вопрос несколько раз в списках рассылки couchdb, но так и не получил ответа.

Есть ряд вещей, которых отсутствует couchdb.

Одним из них является защита на уровне документа, которая:

  • позволяет только определенным пользователям просматривать документ
  • фильтровать документы, проиндексированные в представлении пользователяуровень разрешений базы

Я не думаю, что есть решение вопросов разрешения с текущей реализацией couchdb.

Одним из решений было бы использование внешнего инструмента индексирования, такого как luceneи пометьте свои документы правами пользователя, а затем выполните запрос lucene с определением прав пользователя, чтобы получить документы.Это также подразумевает дополнительную нагрузку на ваш сервер (ы) (lucene требует JVM) и дополнительную задержку для доступности данных (время индексации lucene ...)

Что касается решения для нескольких баз данных, то здесь естьРеализации языковой инфраструктуры, которые просто не позволяют использовать более одной базы данных (например, couch_potato для Ruby).

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

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

Поэтому, если что-то не реализовано в ядре кушетки для управления авторизацией на уровне документов, CouchDB не подходит для управления данными с ограничениями конфиденциальности.

1 голос
/ 05 ноября 2010

Не хватает множества деталей о том, что вы пытаетесь выполнить, как выглядят данные, поэтому сложно дать конкретную рекомендацию.Возможно, вы сможете создать базу данных для каждого пользователя и скопировать элементы в базу данных каждого пользователя (для описанного вами варианта использования DM).Каждый пользователь сможет получить доступ только к своей собственной базе данных, и тогда у вас будет пользователь-администратор, который сможет получить доступ ко всем базам данных.Если вам потребуется позднее обновить эти записи, копирование их в несколько баз данных может быть не очень хорошей идеей, и тогда вы можете подумать, хотите ли вы управлять разрешениями на уровне, отличном от хранилища.несколько баз данных, я рекомендую взглянуть на lounge и bigcouch, которые используют разные подходы.

http://tilgovi.github.com/couchdb-lounge/ http://support.cloudant.com/faqs/views/chained-mapreduce-views

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...