Update docs on private DB security about superlogin

[colinskow]

I agree the README needs some clarity. I am going to leave this issue open to remind me.

[colinskow]

@SukantGujar you should find the answer to your question in the Database Security section of the README. SuperLogin doesn't do it for you (except on Cloudant). You need to study up on CouchDB security best practices and apply them yourself.

You can use the user-db-added event to seed a validate_doc_update design doc.

If you have read the README and the articles linked and are still having trouble let me know.

[SukantGujar]

Yes Colin, I went through the Readme and from the security best practices link as well (thanks, it was really very thoughtful of you to provide that). As pointed out by Matt in his blog, CouchDB security is not very intuitive and I am still trying to understand it 😃 . I just wanted to know if Superlogin already gives me easier means to go ahead and secure private DBs, over vanilla CouchDB.

About having authorization check within validate_doc_update, wouldn't Superlogin already add it for me if I keep it in one of the design docs used for privateDB? Then maybe I won't need to do it myself explicitly.

After posting this question yesterday, I went through CouchDBs documentation on security. Now I am inclining towards adding the private DB owner to its members collection which should ensure only the owner can access it for read/write/replication needs. What are your thoughts?

[colinskow]

If validate_doc_update is inside a designDoc under userDBs.model then it should automatically be seeded.

SuperLogin will automatically add the private DB owner's session token to its members collection when they login, and will remove them when they log out of the session. You don't need to do this yourself.

In addition if you look in config.example.js under userDBs.defaultSecurityRoles you and copy what I have there it will block anonymous rights by default. (Test it afterward to make sure. You will need to do this manually for databases that already exist.)

[SukantGujar]

Great, so looks like Superlogin already takes care of some of the steps to ensure privateDBs remain accessible only to their owners. IMHO, it may help adopters if the readme has some more clarity on the concept of privateDBs like how they are initialized and what default security features are already added. And what responsibilities should be handled by the adopters.

Thanks for all your help Colin, I am closing this issue.