Members list: Are we going to use CouchDB admins?

[paulbert]

I made a few adjustments to the list of members that we're using to make it work with the CouchDB in the Admin Party mode. The problem is that this solution will not work if we decide to use CouchDB admins. I'll link the PR to this momentarily.

@dogi @lmmrssa @leonardmensah Do any of you have a thought on whether we should use CouchDB admins or leave the databases in Admin Party mode?

[lmmrssa]

@paulbert if you keep it in admin mode then it does not have any security, right? then anyone can read or write to couchDB. If that's the case then we will have to keep direct access to couchDB hidden and use authentication from application.
@dogi which approach will you like to keep. Making DB secure or revoking direct access to DB

[dogi]

@paulbert and @lmmrssa can we see some documentation links to this problem ...

[dogi]

http:https://docs.couchdb.org/en/2.0.0/intro/security.html
http:https://docs.couchdb.org/en/2.0.0/api/database/security.html

[empeje]

We shouldn't use CouchDB admin mode and shouldn't use direct access to DB, as mentioned by @lmmrssa . I think I have explained this point very detail in some conversation talk.

[paulbert]

@empeje @dogi @lmmrssa To clarify, by "admin mode" you mean the Admin Party? "Admin mode" to me sounds like using CouchDB administrators, but the Admin Party is for leaving the CouchDB server open.

I'm not convinced we should not be sending requests directly to CouchDB from the app. CouchDB is both a server and a DB, so writing different server code to authenticate & forward requests to the CouchDB server seems redundant to me.

The client will be accessing the CouchDB on the same domain, but different port. Domain name is available in JavaScript so it's just a simple change to remove the static '127.0.0.1' and change it to reference the current domain name.

That was the main concern I understood from you during the meeting last week, but please let us know if you have other concerns about this setup.

[lmmrssa]

@paulbert Yes you are correct, if we are keeping it publicly accessible directly then we need to turn off "Admin mode" and create admin user for couchDB.

Other thing is, based on the way our application has multiple instances and they need to be able to write to couchDB of next instance which will require the admin credential to be public as well. Which does not seem to be safe. For this case we want to wrap authentication by application which will call couchDB authentication internally. Only difference will be then we can modify authentication based on current user session or by other means, it does not need to be administrator user to be public.

If confusion still persist then we can have this talk on angular meeting to come on conculsion

[empeje]

Hi @paulbert and @lmmrssa

I don't have much knowledge with CouchDB, but @lmmrssa solution is seems to fit our need.