CouchDb чтение аутентификации с использованием списков

Question

Я смотрю на портирование веб-сайта в CouchDB, и это выглядит очень интересно.

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

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

Я думал реализовать аутентификацию в списках и ограничить весь доступ к CouchDb этими списками. Это ограничение может быть применено с помощью простых предложений mod_rewrite в Apache, используемых в качестве обратного прокси-сервера. Списки просто извлекают строку и проверяют userCtx по ACL документа. Что-то вроде:

function(head, req) {
  var row;
  while (row = getRow()) {
     if (row.value.ACL[req.userCtx.name])
       send(row.value);
     else
       throw({unauthorized : "You are not allowed to access this resource"});
}

Поскольку у меня нет опыта работы с CouchDB, и я нигде не читал об этом подходе, я хотел бы знать, может ли этот подход работать.

Это способ реализации доступа для чтения или я злоупотребляю списками для неправильной цели? Разве я не ожидаю, что такое простое решение возможно с CouchDB?

Answer 1

Apache mod_rewrite - это средний уровень, поэтому неясно, что вы имеете в виду, когда говорите, что средний уровень не подходит.

Реализация политики безопасности, основанной на данных в couchdb, вполне подойдет.Однако цена заключается в том, что вы несете ответственность за правильность реализации.Это не так плохо, как кажется.Помните, что люди давно делают это с веб-приложениями MySQL.

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

• Есть две заявки, моя и ваша
• У меня есть доступ на чтение к моей ставке, которая составляет 10 долларов, но я не могу прочитать вашу ставкудокумент из-за политики промежуточного программного обеспечения
• Однако я обнаружил представление, которое вычисляет среднее значение всех ставок.Средняя стоимость составляет 7,50 долларов.Поэтому я знаю, что вы предложили 5 долларов США, и я понизлю свою ставку до 6

Другими словами, если вы используете CouchDB API, вам нужно по крайней мере добавить в белый список эти запросыкоторые разрешены.И помните, правила vhost и rewrite выполняются внутри CouchDB, поэтому простого просмотра входящего запроса может быть недостаточно.

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

Answer 2

Обычно достаточно ограничить доступ к определенным представлениям - это можно сделать с помощью списков, как вы предложили (спасибо за идею).Используя неопознанные идентификаторы для документов, у вас уже есть какой-то контроль доступа к документам.Я бы не стал перебирать строки и проверять там разрешения, но я не думаю, что это тоже большая проблема.

Некоторые упоминали здесь, что целью списков является изменение формата - я нене согласен, так как даже в официальном руководстве CouchDB говорится, что списки могут даже создавать документы json.

Другой способ - ограничить количество пользователей по базе данных и использовать выборочную репликацию, поэтому одна база данных будет содержать только данные, определенные определенной группой пользователей.разрешен доступ.См. аутентификация чтения couchdb На самом деле это не для пользователя, но, в любом случае, вариант для вас.Подробнее о отфильтрованной репликации см. http://wiki.apache.org/couchdb/Replication

Редактировать : Я только что пришел к прекрасной идее принудительного применения пользовательских разрешений для каждого документа через списки с лучшей производительностью:

1. Вы передаете имя пользователя в качестве аргумента представлению и соответственно фильтруете.
2. В списке, использующем представление, вы проверяете, является ли данное имя пользователя аргумента идентичным реальному пользователю.

Преимущество в том, что CouchDB, насколько я знаю, внутренне использует кэширование для представлений.Я не уверен, как кеширование работает со списками.Также я думаю, что итерация и фильтрация в представлениях обычно быстрее, чем в списках.

Answer 3

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

Сначала , вам нужно что-то перед CouchDB, чтобы заблокировать любой запрос на чтение,это не передает через список fn, который реализует ACL._all-docs, запросы с reduce=true, прямые GETs документов - все и многие другие должны быть заблокированы.Простейший способ - использовать маски Apache и regexp.

Second , вы должны понимать, что вы не можете простым способом контролировать доступ к вложениям.Хотя вы можете заблокировать любой запрос на чтение, который не соответствует вашему шаблону /db/_design/ddoc/_list/list/view, вы не можете создать эффективную пару view + list, чтобы обеспечить контроль доступа к вложениям.

Это абсолютно невозможно для CouchDB 1.5 и более ранних версий - индекс представления не может включать данные вложения.Это почти невозможно в CouchDB 1.6, так как обработка вложений, закодированных в base64, поскольку JSON - это процессор и ОЗУ.Причина проста - функции списка не являются потоками.Это означает, что сначала весь ответ представления fn захватывается и сериализуется, затем процессор списка снова десериализует его, а затем результат обрабатывается с использованием функции списка.А потом снова сериализуется.

Answer 4

Я не уверен, что использование списка - лучший вариант для ограничения доступа к ресурсам, так как список - это функции, которые используются для визуализации представления в определенном формате (RSS, CSV, файлы конфигурации, HTML, ... ).

Рассматривали ли вы использование документа, содержащего пользователей и их разрешения? Я нашел сообщение Kore Nordmann , в котором объясняется, как преобразовать классического пользователя / группу / разрешения из реляционных баз данных в модель CouchDB:

В зависимости от своих прав пользователь может иметь доступ только к набору определенных представлений.

CouchDB предлагает функции проверки, но они вызываются только при создании или обновлении документа. В книге O'Reilly говорится, что " Система аутентификации является подключаемой, поэтому вы можете интегрироваться с существующими сервисами для аутентификации пользователей в CouchDB с использованием уровня http, интеграции LDAP или другими средствами ». Но поскольку вы упомянули средний уровень, это не вариант, список может быть временным решением, пока в CouchDB не будет добавлена ​​дополнительная поддержка аутентификации.