I am trying to understand how CouchDB work. Does it come bundled up with separate Apache or does it use the Apache in the system. I am trying to understand how it determines where to serve the site and how are different directions done. This is important information because I am trying to understand how to implement the Apache 2.2 mod-proxy -module here with it. Do I need to tune CouchDB or do I need to tune a separate Apache process? Suppose you have 10 CouchDB processes and you want to direct their results to siteA, how can you do that?
Sorry I am now vague but I am trying to understand how to combine different things from one Site to another, having different authorization-cookies etc. I am having a problem where I have two separates sites hello.com/myCouchDb/ and hallo.de/someOthersite.html working separately. When I merge the codes, the authentication fails — I think there are at least three different solution candidates:
A) redirect the verification things from the other site to another (a bit hackish) and/or
B) somehow configure the CouchDB Apache -settings, I have tried in Futon but failed.
C) store the authentication cookies to some dir or db and refresh them when they become old (or use never-old cookies)
So how can I merge different CouchDB -instances together with different authentication settings? Suppose you have ten people with different authentication cookies and you want to get them somehow incorporated to the same site. How can you do it? Do you tune network -settings, Apache -settings or CouchDB -settings? Or do you just stores the cookies to some directory or DB that you refresh every time they become old?
P.s. I am the admin so do not worry about the OAuth2.0, I have the authentication-cookies to do whatever I want with the different instances. I just cannot understand how to merge the different instances.
Perhaps related
It sounds like you’re confused about the structure of CouchDB. CouchDB is a native JSON Database that has an HTTP API. That API is provided via Mochiweb, an Erlang based webserver that is bundled inside CouchDB. There’s only one CouchDB server running, but it runs inside the Erlang Virtual Machine (BEAM) and has a fundamentally different architecture to the typical Apache httpd approach.
Regarding authentication, CouchDB has a per-instance (server) _users database that contains passwords and minimal account details. As an admin you can see this using Futon, although normal users only have access to their own profile. You can assign users into various roles, and then apply those roles and users to each database. Once the _security object is set on a DB, you need to be authenticated to read, and you can use validation update functions to enforce constraints on write. Some brief information on http://blog.couchbase.com/what%E2%80%99s-new-couchdb-10-%E2%80%94-part-4-security%E2%80%99n-stuff-users-authentication-authorisation-and-permissions and http://blog.mattwoodward.com/2012/03/definitive-guide-to-couchdb.html as well as on the wiki.