CouchDB - выяснение безопасности базы данных - PullRequest
6 голосов
/ 29 марта 2011

CouchDB предлагает проверку перед тем, как разрешить вставку объекта / строки в базу данных.Это гарантирует, что если у вас есть общедоступное приложение для кушетки, ваша база данных не будет заполнена мусором никем.

User <-> CouchDB

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

User -> Ruby -> MySQL
User <- Ruby <- MySQL

Как вы доверяете пользователю выполнять административные задачи, когда ему нельзя доверять?

Например, как бы вы сделали что-то вроде «проверки электронной почты» перед вставкой строки пользователя с помощьюпросто couchDB?Вы не можете позволить пользовательскому агенту вставить строку - потому что они будут заполнять систему учетными записями спама.С другой стороны, нет среднего слоя, который мог бы вставить строку после того, как они нажмут на ссылку в электронном письме.

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

Тогда node.js может отслеживать канал _changes и отправлять электронное письмо активации, покасоздание новой записи в закрытой таблице (например, email_confirm) (node.js будет служить доверенным промежуточным уровнем).Если пользователь щелкает эту ссылку и возвращается, то ... [unknown] ... и node.js может, наконец, создать запись в личной таблице пользователя (user).

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

В качестве дополнительной справки давайте представим обсуждение, основанное на couchdb, на которое любой может зарегистрироваться.Мы не хотим позволять кому-либо напрямую отправлять контент без какой-либо проверки - но все пользовательские агенты напрямую запускают систему .(Таблицы будут Thread, Comment, & User).Как это будет работать?

Ответы [ 3 ]

3 голосов
/ 06 апреля 2011

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

Использование проверки и изменения couchdb _design/_auth может быть хорошей идеей для добавления email, email_verified и случайно сгенерированной email_verification_code в _users базу данных, когда пользователь запускает регистры.

Для отправки почты, получения подтверждения, повторной отправки подтверждения вы можете использовать внешние процессы. (для примера использования внешнего процесса вы можете проверить couchdb-lucene).

И, наконец, вы можете снова выполнить быструю проверку в _design / _auth в процессе обновления пользователя, если проверочный код совпадает, и добавить роль verified_user для этого пользователя.

Таким образом, все ваши запросы будут проходить через couchdb, вы будете использовать внешний процесс только тогда, когда вам нужно отправить письмо и получить подтверждение.

Редактировать: Забыл добавить (поскольку это было довольно очевидно), я бы добавил роль verify_user для читателей базы данных.

1 голос
/ 04 апреля 2011

После разговора с некоторыми людьми в IRC #couchdb кажется, что они не могут найти способ сделать что-то административное (например, пользователи активации, которые нажимают на ссылку электронной почты) без использования "внутреннего" процесса, такого как сервер node.js, который отслеживает фид _changes.

Я надеялся на чистое приложение couchdb - но кажется, что у couchdb еще есть небольшие пути.

Тем не менее, хорошая новость заключается в том, что вы можете передать 80% логики / обработки ваших приложений вашим пользователям. Остальные 20% будут: 1) экземпляром node.js для таких вещей, как отправка электронных писем или проверка recaptcha, и 2) функциями проверки записей, выполняющимися в вашем couchdb, и 3) функциями отображения / уменьшения (запроса). Эти три вещи не могут быть переданы чему-то «ненадежному», например, агенту пользователя.

1 голос
/ 31 марта 2011

Не могли бы вы просто использовать Проверка CouchDb ?

Пользователи могут быть помечены.После регистрации пользователь добавляется в базу данных пользователей.Он получает свою почту и затем помечается как «действительный: истина» или что-то в этом роде после ответа на это письмо или перехода по ссылке.

С помощью валидации пользователи могут не только «входить / выходить», но также может быть реализована авторизация доступа с более детальными правами доступа.Например: Отметить только те темы, которые решены, если кто-то является автором, администратором или кем-то еще ...

Или это кажется неосуществимым?

...