Hi, we are using a combination of a reverse proxy, an API component and "db per user" though not using the couchdb functionality since we implemented our own earlier. The reverse proxy ensures only the per user dbs are reachable from the outside, all other requests have to go through the api. In general users work on their own db, some daemons running on the central dbs changes feed distribute documents to different users. Master data is not distributed to the user dbs, this would blow up the databases, but is queried via the API. In our case this is always a user activity. In general all the API does is to get the _user document from the DB, for some of the views only access to the view is checked, for some views additional parameters are injected into the request parameters and in some cases we sadly have to parse the view result. Finished work then again is submitted to the API which does all kinds of permission checks. We work on a complete different data domain than a CMS, but i guess a combination of both concepts, reverse proxy & API and db-per-user could work very well for a CMS, too.
regards, Stefan Am Mi., 25. Juli 2018 um 12:04 Uhr schrieb Rene Veerman < [email protected]>: > and how about using custom users and groups (roles) tables, combined with > view functions that query permissions settings in docs? > that way my CMS' users and groups stay seperate from couchdb's, which can > be seen as a plus, i think. > but i am worried about accesses to my couchdb using credentials found in my > javascript and accesses of the data without using the assigned view > functions. > > i'm not sure db-per-user has been properly debugged already; it was broken > in 2.10 and the current version is 2.1.2 > > On Tue, Jul 24, 2018 at 9:45 PM Jan Lehnardt <[email protected]> wrote: > > > On top of what Joan mentioned, we’re planning per-doc permissions > > for 3.0, but it’s ways out, so don’t wait for it. But if db-per-user > > is good enough for now, you’ll be able to upgrade to the new model > > later. > > > > Best > > Jan > > — > > > > > On 24. Jul 2018, at 20:34, Joan Touzet <[email protected]> wrote: > > > > > > Right now, there is no document-level security in CouchDB unless you > > enforce > > > it yourself using a proxy server of some sort. You can then enable the > > proxy > > > authentication solution in CouchDB and handle all of the permissions > > yourself. > > > > > > Note that this breaks down if you want to allow end users to replicate > > to and > > > from the databases, or use the bulk endpoints. VDU functions generally > > aren't > > > sufficient to enforce detailed levels of modifications to documents. > > > > > > You'll want to look into the database-per-user approaches for CouchDB, > > > including the built-in "couch_peruser" functionality we provide. This > > lets you > > > have a single database per user, and use the power of replication to > > replicate > > > that user's data to (or from) a central database for later analytics > > work if > > > you need. > > > > > > -Joan > > > > > > ----- Original Message ----- > > > From: "Rene Veerman" <[email protected]> > > > To: [email protected] > > > Sent: Tuesday, July 24, 2018 1:56:28 PM > > > Subject: permissions specific to each document? > > > > > > is this possible in couchdb? > > > > > > suppose i have a database 'tree node data', > > > and several roles defined in the couchdb. > > > > > > i'd like to be returned only those tree node documents that the current > > > user may access. > > > > > > in general, i'd like to outsource my entire CMS' users and roles and > > > permissions system to couchdb. is this possible, and if so, what's the > > best > > > way to go about it? > > > > -- > > Professional Support for Apache CouchDB: > > https://neighbourhood.ie/couchdb-support/ > > > > >
