CouchDB - Figuring out database security
CouchDB offers validation prior to allowing an object/row to be inserted into the database. This make sure that if you have a public facing couch application, you're database won't be filled with junk by just anyone.

    User <-> CouchDB

However, I'm tring to figure out what that looks like comming from the standard application design process where you have a [trusted middle layer that does much of the auth work][1]. For example, most apps place Ruby or PHP between the database and user agent which allows the application to figure out information about the user agent before allowing something like a post to be saved to the database.

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

**How do you trust the user to do administrative tasks when the user can't be trusted?**

For example, how would you do something like "email verification" prior to inserting a user row using just couchDB? You can't let the *user agent insert the row* - because they would fill the system with spam accounts. On the other hand, there is no middle layer either that can insert the row after they click the link in the email.

How about this, I would assume that you would allow anyone to enter their email by creating a new record in a public table like `email_verify`. This is something that a public user agent could do as the table would not do anything in the application - it would just be a holding tank.

Then node.js could track the _changes feed and send an activation email while creating a new entry in a private table (like `email_confirm`) (node.js would serve as a trusted middle layer). If the user clicks that link and comes back then... [unknown] ... and node.js could finally create a record in the private user table (`user`).

At this point we could then rely on couchdb validation for the rest of the application since we got a confirmed user account created.

  [1]: http://blog.couchbase.com/whats-new-in-couchdb-1-0-part-4-securityn-stuff
CouchDB - Figuring out database security
===

CouchDB offers validation prior to allowing an object/row to be inserted into the database. This make sure that if you have a public facing couch application, you're database won't be filled with junk by just anyone.

    User <-> CouchDB

However, I'm tring to figure out what that looks like comming from the standard application design process where you have a [trusted middle layer that does much of the auth work][1]. For example, most apps place Ruby or PHP between the database and user agent which allows the application to figure out information about the user agent before allowing something like a post to be saved to the database.

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

**How do you trust the user to do administrative tasks when the user can't be trusted?**

For example, how would you do something like "email verification" prior to inserting a user row using just couchDB? You can't let the *user agent insert the row* - because they would fill the system with spam accounts. On the other hand, there is no middle layer either that can insert the row after they click the link in the email.

How about this, I would assume that you would allow anyone to enter their email by creating a new record in a public table like `email_verify`. This is something that a public user agent could do as the table would not do anything in the application - it would just be a holding tank.

Then node.js could track the _changes feed and send an activation email while creating a new entry in a private table (like `email_confirm`) (node.js would serve as a trusted middle layer). If the user clicks that link and comes back then... [unknown] ... and node.js could finally create a record in the private user table (`user`).

At this point we could then rely on couchdb validation for the rest of the application since we got a confirmed user account created.

  [1]: http://blog.couchbase.com/whats-new-in-couchdb-1-0-part-4-securityn-stuff