2011/7/19 Javier Rodríguez Escolar <[email protected]>: > Hello, > > I have been reading for a while about the existing possibilities to restrict > the read access to a database in which different users write. I mean, all > users should be able to write, but they should only read what they have > written. As far as I can read a common workaround to carry out this issue > is to create a “2.1 layer architecture” as follows: > > - There is a database per user. The user's name will be added to the > _security object. > - There is a private master database. The admin’s name will be added to > the _security object. > - There is a public database. > - There is an external server in charge of copying the data from the > public database to the private one. > > > A very common way to proceed is to let the users write in a public database > and use an external server (NodeJS) to listen for changes on the public > database, move the data to the private master database and remove it from > the public database. To my mind, this approach doesn’t seem to be very > secure since any other external server might be monitoring the changes in > the public database so the security of critical data might be compromised. > Wouldn’t be better to have a middle layer when managing critical data? I’m > newbie to Couchdb so I’m probably missing something.
Yes. A middle layer is the way to go if you really want to get data straight into a private database. Thanks everyone for suffering through these workarounds. The community has been discussing more access control features for a long time. It's a delicate balance of trying to fulfill everyone's needs (or at least 80% of them), not destroying performance in the process of adding more controls, and keeping the API simple and elegant. I think the mailing list is no longer the place to discuss these things because conversations go for a while, stall, and then resurface with the same issues re-hashed. Perhaps a wiki page about it could serve as a working, evolving draft? -R > > Thanks and best regards, > > Javi > > > 2011/7/11 Jason Smith <[email protected]> > >> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes >> <[email protected]> wrote: >> >> Fortunately, users with write access are not admins. They may not >> >> modify design documents. All of their changes are subject to design >> >> documents' validate_doc_update() function. >> > >> > I would be *overjoyed* to hear that you are right and the documentation >> at >> > [0] is wrong: >> >> database admins - Defined per database. They have all the privileges >> > readers have plus the privileges: write (and edit) design documents, >> > add/remove database admins and readers, set the database revisions limit >> > >> > (/somedb/_revs_limit API) and execute temporary views against the >> database >> > (/somedb/_temp_view API). They can not create a database and neither >> delete >> > a database. >> >> D'oh, Marcello posted a pithy and timely answer while I had lunch. >> I'll send anyway. >> >> The typical setup is: >> >> * 1 server admin >> * 0 or more database admins (name or roles in _security.admins) >> * An admin deploys a design document >> * Several normal users (name or roles in _security.readers but *not* >> admins) >> >> "readers" is a misnomer. It really means "members." Read access is >> database-wide, write access is at the pleasure of >> validate_doc_update(). >> >> To that end, Chris changed CouchDB so that future releases will use >> the "members" field. He committed his change last Thanksgiving >> weekend. Thanks, Chris! >> >> > I'm gonna set up a little experiment in the morning (when I can think >> > clearly) to find out for myself. The _revs_limit PI and temporary views >> are >> > scary too. >> >> I strongly encourage an experiment. 15 or 20 minutes of poking around >> will make things very clear. >> >> Cloudant has a brilliant UI to impose more intuitive and traditional >> security policies for exactly this reason. >> >> >> I call it a 2.5-layer architecture >> >> because there is no middleware, but it still requires a third >> >> component, to watch over things. The drop box would be amazing; >> >> however I am still happy with my architecture because bugs or crashes >> >> in the third component are not so devastating to the user experience. >> > >> > The great thing about this architecture is that you can easily have >> CouchDB >> > monitor the third party stuff and keep it running with external OS >> processes >> > [1]. I like the term '2.5-layer' :D. >> >> Is it too late to change the name to "2.1-layer"? >> >> * Hints that the extra step is not going to break your back >> * Kind of like 5.1 surround sound >> >> > By the way, why hasn't this been implimented before? It seems strange to >> me. >> > Is there something inherent in the architecture of CouchDB that makes >> this >> > difficult? >> >> I think it is a matter of time. The people in a position to implement >> it have not felt quite enough pressure. >> >> /me whistles innocently. >> >> -- >> Iris Couch >> >
