Создайте пользователя только для чтения и записи только в кластере Couchdb 2.1 - PullRequest
0 голосов
/ 30 августа 2018

Недавно я создал кластер 3 сервера couchdb 2.1 и пытался создать некоторую защиту приложений. Идея состоит в том, чтобы иметь пользователя только для записи, который будет предоставляться приложениям, которым требуется запись в базу данных, и пользователя только для чтения, который будет использоваться приложениями, которые читают из базы данных. Разработчикам будет предоставлен еще один пользователь, доступный только для чтения. Проблема в том, что я не могу найти документацию по этому вопросу. У нас было это ранее на старой установке 1.6, но это было установлено до моего времени. Любое руководство приветствуется.

1 Ответ

0 голосов
/ 06 сентября 2018

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

Базы данных только для записи немного сложнее. Вы должны установить прокси-сервер перед базой данных, который разрешает доступ только к интерфейсам записи и блокирует доступ к интерфейсам чтения. У меня был проект, в котором мы достигли этого, поставив прокси-сервер впереди и указав его на интерфейсе перезаписи на couchdb.

Прокси указывает на

https://couchserver.com/databasename/_design/app/_rewrite

Дизайн документа выглядит как

{
   "_id": "_design/app",
   "rewrites": [
       {
           "to": "../../_bulk_docs",
           "from": "/db/_bulk_docs",
           "method": "POST"
       },
       {
           "to": "../../_revs_diff",
           "from": "/db/_revs_diff",
           "method": "POST"
       },
       {
           "to": "../../_local/*",
           "from": "/db/_local/*",
           "method": "GET"
       },
       {
           "to": "../../_local/*",
           "from": "/db/_local/*",
           "method": "POST"
       },
       {
           "to": "../../_local/*",
           "from": "/db/_local/*",
           "method": "PUT"
       },
       {
           "to": "../../../",
           "from": "/",
           "method": "GET"
       },
       {
           "to": "../../fakedb",
           "from": "/",
           "method": "GET"
       },
       {
           "to": "/../../fakedb",
           "from": "/db/*",
           "method": "GET"
       }
   ]
}

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

https://proxyserver.com/db

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

{
   "_id": "fakedb",
   "_rev": "1-063ad938e0501105d2f304db16dd4970",
   "db_name": "dbname"
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...