easier to test for a role instead and just users to that role.
On 18 July 2011 16:24, Mehdi El Fadil <[email protected]> wrote: > Hi, > > What about storing the list of writers inside the validation function, and > not having these users in the security object of the database? > > Technically, is there a problem in this approach for a write-only database? > > The validation function would have to be updated each time a writer needs to > be added. > > Mehdi. > > On Tue, Jul 12, 2011 at 12:48 AM, Jonathan Geddes <[email protected] >> wrote: > >> Andrew, >> >> There's nothing built in, but there are apparently a couple of possible >> workarounds: >> >> 1. Use the '2.1 layer architecture': have something (like nodejs) listening >> for changes on the public database that moves the data to a private >> database >> and removes it from the public database. >> >> 2. Use the built-in rewriter to limit access to a given database to >> POST/PUT >> (don't allow GET through) >> >> --Jonathan >> >> On Mon, Jul 11, 2011 at 4:27 PM, Andrew Stuart (SuperCoders) < >> [email protected]> wrote: >> >> > Sorry I phrased that badly. >> > >> > Back in the days of Lotus Notes it was possible to have users who were >> able >> > to write into, but not read from a database. Is similar functionality >> built >> > in to CouchDB or must it be enabled by external logic? >> > >> > as >> > >> > >> > >> > >> > On 12/07/2011, at 7:48 AM, Robert Newson wrote: >> > >> > how would one replicate these write-only dropboxes? >> > >> > B. >> > >> > On 11 July 2011 22:13, Andrew Stuart (SuperCoders) >> > <andrew.stuart@supercoders.**com.au <[email protected]>> >> > wrote: >> > >> >> I've followed this thread but it's still somewhat unclear - >> >> >> >> -- is "write only" database access built in/easy to do, or must it be >> >> enabled via some special external logic imposed at the application >> layer? >> >> >> >> as >> >> >> >> On 12/07/2011, at 6:39 AM, Jonathan Geddes wrote: >> >> >> >> One more possible solution: Could I use the rewriter to make sure that >> >> that >> >> only POST and PUT go through to a given database? How secure is this >> >> approach? >> >> >> >> --Jonathan >> >> >> >> On Mon, Jul 11, 2011 at 8:45 AM, Jonathan Geddes >> >> <[email protected]>**wrote: >> >> >> >> Thanks for the responses, everyone. >> >>> >> >>> So I've been using CouchDB for about a year, but I'm only now getting >> >>> into >> >>> the "2.1 Layer Architecture" (cutting back from a 3+ layer). >> >>> >> >>> Apparently I've been using readers and admins wrong all along. I >> thought >> >>> that only admins could write documents. After all, why would I think >> that >> >>> 'readers' could write? I've been a victim of the misnomer! >> >>> >> >>> I still think that the dropbox feature would be immensely useful, and I >> >>> still might take a whack at implementing it. >> >>> >> >>> Thanks for the clarification, >> >>> >> >>> --Jonathan >> >>> >> >>> >> >>> On Mon, Jul 11, 2011 at 1:17 AM, Jason Smith <[email protected]> >> wrote: >> >>> >> >>> 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 >> >>>> >> >>>> >> >>> >> >>> -- >> >> Message protected by MailGuard: e-mail anti-virus, anti-spam and >> content >> >> filtering.http://www.**mailguard.com.au/mg< >> http://www.mailguard.com.au/mg> >> >> Click here to report this message as spam: >> >> https://login.mailguard.com.**au/report/1CGUOUsAWN/** >> >> 2BVxdPfDhfeJK4SLOnz0gl/1< >> https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1> >> >> >> >> -- >> > Message protected by MailGuard: e-mail anti-virus, anti-spam and content >> > filtering.http://www.**mailguard.com.au/mg< >> http://www.mailguard.com.au/mg> >> > Click here to report this message as spam: >> > https://login.mailguard.com.**au/report/1CGW2fhE4N/** >> > 5SE2wTOEjJss04ObshZ4q9/1< >> https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1> >> > >> >
