CouchDB-выяснение безопасности базы данных
CouchDB предлагает проверку до разрешения объекта / строки для вставки в базу данных. Это убедитесь, что если у вас есть публичное приложение диван, вы база данных не будет заполнена мусором только кто-то.
User <-> CouchDB
тем не менее, я пытаюсь выяснить, как это выглядит из стандартного процесса проектирования приложений, где у вас есть доверенный средний слой, который делает большую часть работы auth. Например, большинство приложений на Ruby или PHP между базой данных и агентом пользователя, который позволяет приложению выяснить информацию о агенте пользователя, прежде чем разрешить что-то вроде сообщения для сохранения в базе данных.
User -> Ruby -> MySQL
User <- Ruby <- MySQL
как Вы доверяете пользователю выполнять административные задачи, когда пользователю нельзя доверять?
например, как бы вы сделали что-то вроде "проверки электронной почты" перед вставкой строки пользователя, используя только couchDB? Вы не можете позволить агент пользователя вставить row - потому что они заполнят систему спам-аккаунтами. С другой стороны, нет среднего слоя, который может вставить строку после нажатия на ссылку в письме.
как насчет этого, я бы предположил, что вы позволите любому ввести свою электронную почту, создав новую запись в общедоступной таблице, такой как email_verify. Это то, что агент пользователя может сделать таблицу не в заявке - это будет холдинг бак.
затем узел.js может отслеживать канал _changes и отправлять электронное письмо активации при создании новой записи в частной таблице (например,email_confirm) (узел.js будет служить надежным средним слоем). Если пользователь нажимает эту ссылку и возвращается... [неизвестный. ].. и узел.js может, наконец, создать запись в таблице private user (user).
на данный момент мы могли бы полагаться на проверку couchdb для остальной части приложения, так как мы получили подтвержденную учетную запись пользователя создан.
как можно больше сведений давайте представим дискуссию, построенную на couchdb, для которой любой может зарегистрироваться. Мы не хотим позволять кому-либо напрямую отправлять контент без какой - либо проверки-пока все агенты пользователей непосредственно запустить систему. (Таблицы будут Thread, Comment, & User). Как это будет работать?
3 ответов
Я бы подумал о добавлении ролей существующим пользователям в этой проблеме.
использование проверки couchdb и изменение _design/_auth может быть хорошей идеей, чтобы добавить email, email_verified и генерируется случайным образом email_verification_code на _users база данных при первой регистрации пользователя.
для отправки почты, получения подтверждения, повторной отправки подтверждения Вы можете использовать внешние процессы. (для примера использования внешнего процесса вы можете проверить couchdb-lucene).
и, наконец, вы можете снова сделать быстрая проверка в _design / _auth в процессе обновления пользователя, если код проверки совпадает и добавить verified_user роли для этого пользователя.
таким образом, все ваши запросы будут проходить через couchdb, вы будете использовать внешний процесс только тогда, когда вам нужно отправить почту и получить подтверждение.
Edit: забыл добавить (так как это было довольно очевидно), я бы добавил роль verified_user для чтения баз данных.
не могли бы вы просто использовать проверка CouchDb ?
пользователи могут быть помечены. После регистрации пользователь добавляется в базу данных пользователей. Он получает свою почту, а затем помечается "valid:true" или что-то вроде этого при ответе на эту почту или щелчке по ссылке.
с проверкой пользователи могут не только "войти/выйти", но и авторизация доступа может быть реализована с более гранулированными правами доступа. Например: Только маркировать потоки, если один автор, администратор, кто угодно...
или это кажется невыполнимым?
после разговора с некоторыми людьми на # couchdb IRC, кажется, что они не могут понять, как сделать что-то административное (например, пользователи активации, которые нажимают на ссылку электронной почты) без использования "бэкэнд" процесс, как узел.JS-сервер, который отслеживает канал _changes.
Я надеялся на чистое приложение couchdb-но, похоже, couchdb все еще есть немного способов пойти.
еще, хорошая новость заключается в том, что вы можете передать 80% ваших приложений логика / обработка для ваших пользователей. Остальные 20% будут 1) узлом.экземпляр js для таких вещей, как отправка электронной почты или проверка recaptcha и 2) функции проверки записи, запущенные в вашем couchdb, и 3) функции map/reduce (query). Эти три вещи не могут быть выгружены на что-то" ненадежное", как пользовательский агент.