You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jonathan Geddes <ge...@gmail.com> on 2011/07/11 06:21:53 UTC
no 'writers' section in _security killing me
I keep running into a few recurring themes that make couchapps just not
scale for me. I believe that with just a few extra CouchDB features, the
couchapp model could scale to encompass ANY web application.
The missing feature that is currently bumming me out is the lack of a
writers section in the _security object of a database. Here are a few
examples where I've wanted this feature:
1. User feedback. I'd love to just throw up a simple couchapp with a
database that anyone can write to, but only certain users (or a certain
role) can read from. I can't do this currently because if a user can write
to a given database, they can also read from that database.
2. A sort of voting feature on an app where users should be able to cast
their votes, but not see other users' votes. I can easily ensure that each
user only gets one vote in the validation by making sure the _id on the vote
document matches the user's id. Here I have the same problem as the previous
example. But Also, I can't *really* constrain each user to just one vote
because if the user can write to the database, then they are an admin and
they can change the design doc such that it no longer limits them to one
vote. Then they can vote arbitrarily many times.
3. A messaging system where anyone can write to anyone else's message
database, but not read each others' messages. This is a more general case of
the first example.
I know that I can implement all of these things if I use some kind of
middleware, but it pains me to add additional complexity just for a feature
that I believe should be built-in. I also don't want to leave the couchapp
model, because I believe that once I've thrown middleware in front of couch,
it loses its biggest advantage (in my use cases) over its competitors: i'm
no longer querying it directly from the client.
I would love to see the writers section of _security implemented. In fact,
I've been trying to find a way to contribute to CouchDB, and I might take a
whack at implementing this feature myself. Would others find this feature
useful? Is such a feature already on the way? Are there other ways (besides
middleware) of getting these features that I'm too dense to have thought of?
:P
--Jonathan
Re: no 'writers' section in _security killing me
Posted by Max Ogden <ma...@maxogden.com>.
i just wrote an html5 drag and drop uploader for couch, feel free to use it
for your dropbox clone :) http://open211.org/#upload
On Mon, Jul 11, 2011 at 1:39 PM, Jonathan Geddes
<ge...@gmail.com>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
> <ge...@gmail.com>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 <jh...@iriscouch.com> wrote:
> >
> >> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
> >> <ge...@gmail.com> 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
> >>
> >
> >
>
Re: no 'writers' section in _security killing me
Posted by Sean Copenhaver <se...@gmail.com>.
I believe that is the meaning of couchapp. An app completely hosted out of couchdb. It's only 2 physical tiers (couchdb server + browser) but the logical layers are still there for the most part (database -> design doc functions -> browser)
On Jul 11, 2011, at 8:13 PM, "Andrew Stuart (SuperCoders)" <an...@supercoders.com.au> wrote:
> Perhaps I have my terminology wrong.
>
> Im talking about applications in which there is CouchDB and the browser client, and nothing in between - is that single tier or two tier?
>
> as
>
>
>
> On 12/07/2011, at 10:06 AM, Benoit Chesneau wrote:
>
> On Tue, Jul 12, 2011 at 1:14 AM, Andrew Stuart (SuperCoders)
> <an...@supercoders.com.au> wrote:
>> Yes I would like to be able to build "pure" 2 tier CouchApps, and would like
>> to avoid the extra logic.
>>
>> as
>>
> I don't hear your sabir. WHat is a pure 2 tiers couchapp ?
> --
> Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1CGYvOLAif/2ISPCUHlM91wT4VeF0moMW/0
Re: no 'writers' section in _security killing me
Posted by "Andrew Stuart (SuperCoders)" <an...@supercoders.com.au>.
Perhaps I have my terminology wrong.
Im talking about applications in which there is CouchDB and the
browser client, and nothing in between - is that single tier or two
tier?
as
On 12/07/2011, at 10:06 AM, Benoit Chesneau wrote:
On Tue, Jul 12, 2011 at 1:14 AM, Andrew Stuart (SuperCoders)
<an...@supercoders.com.au> wrote:
> Yes I would like to be able to build "pure" 2 tier CouchApps, and
> would like
> to avoid the extra logic.
>
> as
>
I don't hear your sabir. WHat is a pure 2 tiers couchapp ?
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.http://www.mailguard.com.au/mg
Click here to report this message as spam:
https://login.mailguard.com.au/report/1CGYvOLAif/2ISPCUHlM91wT4VeF0moMW/0
Re: no 'writers' section in _security killing me
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Jul 12, 2011 at 1:14 AM, Andrew Stuart (SuperCoders)
<an...@supercoders.com.au> wrote:
> Yes I would like to be able to build "pure" 2 tier CouchApps, and would like
> to avoid the extra logic.
>
> as
>
I don't hear your sabir. WHat is a pure 2 tiers couchapp ?
Re: no 'writers' section in _security killing me
Posted by "Andrew Stuart (SuperCoders)" <an...@supercoders.com.au>.
Yes I would like to be able to build "pure" 2 tier CouchApps, and
would like to avoid the extra logic.
as
On 12/07/2011, at 9:10 AM, Jonathan Geddes wrote:
I totally agree that this should be built in. It doesn't seem like it
would
be a very difficult change to implement.
--Jonathan
On Mon, Jul 11, 2011 at 5:02 PM, Andrew Stuart (SuperCoders) <
andrew.stuart@supercoders.com.au> wrote:
> Okay I understand now I think - essentially "write only" access
> control for
> a given user is not built-in. Seems like a good thing to be part of
> the
> basic security model - does anyone else agree, or is the general
> consensus
> that this is not something that should be part of the access control
> model?
>
> as
>
>
>
>
>
> On 12/07/2011, at 8:48 AM, Jonathan Geddes 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) <
> andrew.stuart@supercoders.com.**au <an...@supercoders.com.au>>
> 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
>> <an...@supercoders.com.au>
>>>>
>> 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
>>> <ge...@gmail.com>****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 <jh...@iriscouch.com>
>>>> wrote:
>>>>
>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>
>>>>> <ge...@gmail.com> 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.**mailgua**rd.com.au/mg<http://mailguard.com.au/mg
>>> >
>>> <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<https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1
>>> >
>>>>
>>>
>>> --
>>>
>> Message protected by MailGuard: e-mail anti-virus, anti-spam and
>> content
>> filtering.http://www.**mailgua**rd.com.au/mg <http://mailguard.com.au/mg
>> >
>> <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<https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1
>> >
>>>
>>
>>
Re: no 'writers' section in _security killing me
Posted by Jonathan Geddes <ge...@gmail.com>.
I totally agree that this should be built in. It doesn't seem like it would
be a very difficult change to implement.
--Jonathan
On Mon, Jul 11, 2011 at 5:02 PM, Andrew Stuart (SuperCoders) <
andrew.stuart@supercoders.com.au> wrote:
> Okay I understand now I think - essentially "write only" access control for
> a given user is not built-in. Seems like a good thing to be part of the
> basic security model - does anyone else agree, or is the general consensus
> that this is not something that should be part of the access control model?
>
> as
>
>
>
>
>
> On 12/07/2011, at 8:48 AM, Jonathan Geddes 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) <
> andrew.stuart@supercoders.com.**au <an...@supercoders.com.au>>
> 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 <an...@supercoders.com.au>
>> >>
>> 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
>>> <ge...@gmail.com>****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 <jh...@iriscouch.com> wrote:
>>>>
>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>
>>>>> <ge...@gmail.com> 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.**mailgua**rd.com.au/mg<http://mailguard.com.au/mg>
>>> <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<https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1>
>>> >
>>>
>>> --
>>>
>> Message protected by MailGuard: e-mail anti-virus, anti-spam and content
>> filtering.http://www.**mailgua**rd.com.au/mg <http://mailguard.com.au/mg>
>> <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<https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1>
>> >
>>
>>
Re: no 'writers' section in _security killing me
Posted by "Andrew Stuart (SuperCoders)" <an...@supercoders.com.au>.
Okay I understand now I think - essentially "write only" access
control for a given user is not built-in. Seems like a good thing to
be part of the basic security model - does anyone else agree, or is
the general consensus that this is not something that should be part
of the access control model?
as
On 12/07/2011, at 8:48 AM, Jonathan Geddes 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) <
andrew.stuart@supercoders.com.au> 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
> <an...@supercoders.com.au>>
> 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
>> <ge...@gmail.com>**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 <jh...@iriscouch.com>
>>> wrote:
>>>
>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>> <ge...@gmail.com> 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
> >
>
Re: no 'writers' section in _security killing me
Posted by Robert Newson <ro...@gmail.com>.
easier to test for a role instead and just users to that role.
On 18 July 2011 16:24, Mehdi El Fadil <me...@mango-is.com> 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 <geddes.jonathan@gmail.com
>> 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) <
>> andrew.stuart@supercoders.com.au> 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 <an...@supercoders.com.au>>
>> > 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
>> >> <ge...@gmail.com>**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 <jh...@iriscouch.com>
>> wrote:
>> >>>
>> >>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>> >>>> <ge...@gmail.com> 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>
>> >
>>
>
Re: no 'writers' section in _security killing me
Posted by Mehdi El Fadil <me...@mango-is.com>.
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 <geddes.jonathan@gmail.com
> 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) <
> andrew.stuart@supercoders.com.au> 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 <an...@supercoders.com.au>>
> > 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
> >> <ge...@gmail.com>**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 <jh...@iriscouch.com>
> wrote:
> >>>
> >>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
> >>>> <ge...@gmail.com> 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>
> >
>
Re: no 'writers' section in _security killing me
Posted by Jonathan Geddes <ge...@gmail.com>.
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) <
andrew.stuart@supercoders.com.au> 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 <an...@supercoders.com.au>>
> 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
>> <ge...@gmail.com>**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 <jh...@iriscouch.com> wrote:
>>>
>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>> <ge...@gmail.com> 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>
>
Re: no 'writers' section in _security killing me
Posted by "Andrew Stuart (SuperCoders)" <an...@supercoders.com.au>.
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)
<an...@supercoders.com.au> 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
> <ge...@gmail.com>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 <jh...@iriscouch.com>
>> wrote:
>>
>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>> <ge...@gmail.com> 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
> Click here to report this message as spam:
> 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
Click here to report this message as spam:
https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1
Re: no 'writers' section in _security killing me
Posted by Robert Newson <rn...@apache.org>.
how would one replicate these write-only dropboxes?
B.
On 11 July 2011 22:13, Andrew Stuart (SuperCoders)
<an...@supercoders.com.au> 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
> <ge...@gmail.com>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 <jh...@iriscouch.com> wrote:
>>
>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>> <ge...@gmail.com> 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
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1
>
Re: no 'writers' section in _security killing me
Posted by "Andrew Stuart (SuperCoders)" <an...@supercoders.com.au>.
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
<ge...@gmail.com>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 <jh...@iriscouch.com>
> wrote:
>
>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>> <ge...@gmail.com> 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
Click here to report this message as spam:
https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1
Re: no 'writers' section in _security killing me
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Jul 11, 2011 at 10:39 PM, Jonathan Geddes
<ge...@gmail.com> 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
>
yes you can . use "method": "POST" in the rule and add another with "PUT"
Re: no 'writers' section in _security killing me
Posted by Jonathan Geddes <ge...@gmail.com>.
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
<ge...@gmail.com>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 <jh...@iriscouch.com> wrote:
>
>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>> <ge...@gmail.com> 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
>>
>
>
Re: no 'writers' section in _security killing me
Posted by Jonathan Geddes <ge...@gmail.com>.
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 <jh...@iriscouch.com> wrote:
> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
> <ge...@gmail.com> 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
>
Re: no 'writers' section in _security killing me
Posted by Ryan Ramage <ry...@gmail.com>.
I think the pattern that Jens is following would be 2 databases still,
both normal couchdbs. The 'inbox' would have the public key as an
attachment, and allow all who post messages to encrypt with that key.
Then all messages docs would be replicated to the users db. This db
would have private access, so if a private key needs to be stored
safely, it can....thats how I would imagine it anyway.
I still thing the inbox db style that Jason is working on has a lot of
value though.
On Wed, Sep 28, 2011 at 9:59 AM, Zachary Zolton
<za...@gmail.com> wrote:
> For the validation function to decrypt the docs, I'm guessing the
> private key would have to be in the ddoc. Wouldn't users be able to
> read that and thus decrypt everything?
>
> (Sorry, I've been stalking this thread.)
>
>
> On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
>> This would be a great feature; I'd love to see it get in.
>>
>> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>>
>> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>>
>> --Jens
>>
>> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>
>>> A while back, Chris Anderson mentioned an idea for an "inbox database":
>>>
>>> * CouchDB allows non-members (non-readers) to write to the database.
>>> * The validate_doc_update() functions still approve all changes, of course
>>>
>>> I wrote an implementation and submitted the patches to JIRA. I am
>>> hopeful it can be pulled into the 1.3 release.
>>>
>>> https://issues.apache.org/jira/browse/COUCHDB-1287
>>>
>>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> wrote:
>>>> there is a wiki page for this with only one reasonable solution (db per user).
>>>>
>>>> The trick is solve read access for reduce views without violating
>>>> common sense notions of read security. Everything else is easy by
>>>> comparison.
>>>>
>>>> B.
>>>>
>>>> On 19 July 2011 21:11, Randall Leeds <ra...@gmail.com> wrote:
>>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
>>>>>> 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 <jh...@iriscouch.com>
>>>>>>
>>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>>> <ge...@gmail.com> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Iris Couch
>>
>
Re: no 'writers' section in _security killing me
Posted by Jason Smith <jh...@iriscouch.com>.
You could store the private key in the _user document for the user.
That will be available in the userCtx parameter to
validate_doc_update.
Unfortunately, everybody can read the _users database by default, but
that is easily solved by making it an inbox database.
On Wed, Sep 28, 2011 at 11:38 PM, Jens Alfke <je...@couchbase.com> wrote:
> Oops, yeah, hadn't considered that. (I've been mostly working on signatures, not encryption, and for those the validation fn doesn't need access to a private key.)
>
> --Jens
>
> On Sep 28, 2011, at 9:00 AM, "Zachary Zolton" <za...@gmail.com> wrote:
>
>> For the validation function to decrypt the docs, I'm guessing the
>> private key would have to be in the ddoc. Wouldn't users be able to
>> read that and thus decrypt everything?
>>
>> (Sorry, I've been stalking this thread.)
>>
>>
>> On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
>>> This would be a great feature; I'd love to see it get in.
>>>
>>> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>>>
>>> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>>>
>>> --Jens
>>>
>>> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>>
>>>> A while back, Chris Anderson mentioned an idea for an "inbox database":
>>>>
>>>> * CouchDB allows non-members (non-readers) to write to the database.
>>>> * The validate_doc_update() functions still approve all changes, of course
>>>>
>>>> I wrote an implementation and submitted the patches to JIRA. I am
>>>> hopeful it can be pulled into the 1.3 release.
>>>>
>>>> https://issues.apache.org/jira/browse/COUCHDB-1287
>>>>
>>>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> wrote:
>>>>> there is a wiki page for this with only one reasonable solution (db per user).
>>>>>
>>>>> The trick is solve read access for reduce views without violating
>>>>> common sense notions of read security. Everything else is easy by
>>>>> comparison.
>>>>>
>>>>> B.
>>>>>
>>>>> On 19 July 2011 21:11, Randall Leeds <ra...@gmail.com> wrote:
>>>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
>>>>>>> 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 <jh...@iriscouch.com>
>>>>>>>
>>>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>>>> <ge...@gmail.com> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Iris Couch
>>>
>
--
Iris Couch
Re: no 'writers' section in _security killing me
Posted by Jens Alfke <je...@couchbase.com>.
Oops, yeah, hadn't considered that. (I've been mostly working on signatures, not encryption, and for those the validation fn doesn't need access to a private key.)
--Jens
On Sep 28, 2011, at 9:00 AM, "Zachary Zolton" <za...@gmail.com> wrote:
> For the validation function to decrypt the docs, I'm guessing the
> private key would have to be in the ddoc. Wouldn't users be able to
> read that and thus decrypt everything?
>
> (Sorry, I've been stalking this thread.)
>
>
> On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
>> This would be a great feature; I'd love to see it get in.
>>
>> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>>
>> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>>
>> --Jens
>>
>> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>
>>> A while back, Chris Anderson mentioned an idea for an "inbox database":
>>>
>>> * CouchDB allows non-members (non-readers) to write to the database.
>>> * The validate_doc_update() functions still approve all changes, of course
>>>
>>> I wrote an implementation and submitted the patches to JIRA. I am
>>> hopeful it can be pulled into the 1.3 release.
>>>
>>> https://issues.apache.org/jira/browse/COUCHDB-1287
>>>
>>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> wrote:
>>>> there is a wiki page for this with only one reasonable solution (db per user).
>>>>
>>>> The trick is solve read access for reduce views without violating
>>>> common sense notions of read security. Everything else is easy by
>>>> comparison.
>>>>
>>>> B.
>>>>
>>>> On 19 July 2011 21:11, Randall Leeds <ra...@gmail.com> wrote:
>>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
>>>>>> 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 <jh...@iriscouch.com>
>>>>>>
>>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>>> <ge...@gmail.com> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Iris Couch
>>
Re: no 'writers' section in _security killing me
Posted by Zachary Zolton <za...@gmail.com>.
For the validation function to decrypt the docs, I'm guessing the
private key would have to be in the ddoc. Wouldn't users be able to
read that and thus decrypt everything?
(Sorry, I've been stalking this thread.)
On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
> This would be a great feature; I'd love to see it get in.
>
> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>
> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>
> --Jens
>
> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>
>> A while back, Chris Anderson mentioned an idea for an "inbox database":
>>
>> * CouchDB allows non-members (non-readers) to write to the database.
>> * The validate_doc_update() functions still approve all changes, of course
>>
>> I wrote an implementation and submitted the patches to JIRA. I am
>> hopeful it can be pulled into the 1.3 release.
>>
>> https://issues.apache.org/jira/browse/COUCHDB-1287
>>
>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> wrote:
>>> there is a wiki page for this with only one reasonable solution (db per user).
>>>
>>> The trick is solve read access for reduce views without violating
>>> common sense notions of read security. Everything else is easy by
>>> comparison.
>>>
>>> B.
>>>
>>> On 19 July 2011 21:11, Randall Leeds <ra...@gmail.com> wrote:
>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
>>>>> 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 <jh...@iriscouch.com>
>>>>>
>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>> <ge...@gmail.com> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Iris Couch
>
Re: no 'writers' section in _security killing me
Posted by Jens Alfke <je...@couchbase.com>.
This would be a great feature; I'd love to see it get in.
There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
--Jens
On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
> A while back, Chris Anderson mentioned an idea for an "inbox database":
>
> * CouchDB allows non-members (non-readers) to write to the database.
> * The validate_doc_update() functions still approve all changes, of course
>
> I wrote an implementation and submitted the patches to JIRA. I am
> hopeful it can be pulled into the 1.3 release.
>
> https://issues.apache.org/jira/browse/COUCHDB-1287
>
> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> wrote:
>> there is a wiki page for this with only one reasonable solution (db per user).
>>
>> The trick is solve read access for reduce views without violating
>> common sense notions of read security. Everything else is easy by
>> comparison.
>>
>> B.
>>
>> On 19 July 2011 21:11, Randall Leeds <ra...@gmail.com> wrote:
>>> 2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
>>>> 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 <jh...@iriscouch.com>
>>>>
>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>> <ge...@gmail.com> 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
>>>>>
>>>>
>>>
>>
>
>
>
> --
> Iris Couch
Re: no 'writers' section in _security killing me
Posted by Jason Smith <jh...@iriscouch.com>.
A while back, Chris Anderson mentioned an idea for an "inbox database":
* CouchDB allows non-members (non-readers) to write to the database.
* The validate_doc_update() functions still approve all changes, of course
I wrote an implementation and submitted the patches to JIRA. I am
hopeful it can be pulled into the 1.3 release.
https://issues.apache.org/jira/browse/COUCHDB-1287
On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> wrote:
> there is a wiki page for this with only one reasonable solution (db per user).
>
> The trick is solve read access for reduce views without violating
> common sense notions of read security. Everything else is easy by
> comparison.
>
> B.
>
> On 19 July 2011 21:11, Randall Leeds <ra...@gmail.com> wrote:
>> 2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
>>> 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 <jh...@iriscouch.com>
>>>
>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>> <ge...@gmail.com> 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
>>>>
>>>
>>
>
--
Iris Couch
Re: no 'writers' section in _security killing me
Posted by Robert Newson <ro...@gmail.com>.
there is a wiki page for this with only one reasonable solution (db per user).
The trick is solve read access for reduce views without violating
common sense notions of read security. Everything else is easy by
comparison.
B.
On 19 July 2011 21:11, Randall Leeds <ra...@gmail.com> wrote:
> 2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
>> 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 <jh...@iriscouch.com>
>>
>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>> <ge...@gmail.com> 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
>>>
>>
>
Re: no 'writers' section in _security killing me
Posted by Randall Leeds <ra...@gmail.com>.
2011/7/19 Javier Rodríguez Escolar <ja...@gmail.com>:
> 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 <jh...@iriscouch.com>
>
>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>> <ge...@gmail.com> 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
>>
>
Re: no 'writers' section in _security killing me
Posted by Javier Rodríguez Escolar <ja...@gmail.com>.
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.
Thanks and best regards,
Javi
2011/7/11 Jason Smith <jh...@iriscouch.com>
> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
> <ge...@gmail.com> 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
>
Re: no 'writers' section in _security killing me
Posted by Jason Smith <jh...@iriscouch.com>.
On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
<ge...@gmail.com> 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
Re: no 'writers' section in _security killing me
Posted by Max Ogden <ma...@maxogden.com>.
I'd recommend reading
http://blog.couchbase.com/whats-new-in-couchdb-1-0-part-4-securityn-stufffor
an overview of the couch security model
On Sun, Jul 10, 2011 at 11:30 PM, Marcello Nuccio <marcello.nuccio@gmail.com
> wrote:
> 2011/7/11 Jonathan Geddes <ge...@gmail.com>:
> >> 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.
>
> "Users with write access", are users authorized by the
> validation_doc_update functions in the design documents of the
> database:
>
> http://guide.couchdb.org/draft/security.html#validation
>
> Marcello
>
Re: no 'writers' section in _security killing me
Posted by Marcello Nuccio <ma...@gmail.com>.
2011/7/11 Jonathan Geddes <ge...@gmail.com>:
>> 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.
"Users with write access", are users authorized by the
validation_doc_update functions in the design documents of the
database:
http://guide.couchdb.org/draft/security.html#validation
Marcello
Re: no 'writers' section in _security killing me
Posted by Jonathan Geddes <ge...@gmail.com>.
Thanks for the response
>> 1. User feedback. I'd love to just throw up
>
>Often when I work with CouchDB I feel the same way.
LOL! Totally out of context, I love CouchDB. But some user feedback does
make me want to throw up...
> 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.
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 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.
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?
--Jonathan
[0]: http://wiki.apache.org/couchdb/Security_Features_Overview
[1]:
https://github.com/apache/couchdb/commit/c8785113522b8486fab0ba53f2043d94e9b1507f
On Sun, Jul 10, 2011 at 10:49 PM, Jason Smith <jh...@iriscouch.com> wrote:
> On Mon, Jul 11, 2011 at 11:21 AM, Jonathan Geddes
> <ge...@gmail.com> wrote:
> > 1. User feedback. I'd love to just throw up
>
> Often when I work with CouchDB I feel the same way.
>
> > a simple couchapp with a
> > database that anyone can write to, but only certain users (or a certain
> > role) can read from. I can't do this currently because if a user can
> write
> > to a given database, they can also read from that database.
>
> This is the most highly-desired feature I know of. No doubt many
> people are excited to hear your enthusiasm about working on this.
>
> > 2. A sort of voting feature on an app where users should be able to cast
> > their votes, but not see other users' votes. I can easily ensure that
> each
> > user only gets one vote in the validation by making sure the _id on the
> vote
> > document matches the user's id. Here I have the same problem as the
> previous
> > example. But Also, I can't *really* constrain each user to just one vote
> > because if the user can write to the database, then they are an admin and
> > they can change the design doc such that it no longer limits them to one
> > vote. Then they can vote arbitrarily many times.
>
> 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 love to see the writers section of _security implemented. In
> fact,
> > I've been trying to find a way to contribute to CouchDB, and I might take
> a
> > whack at implementing this feature myself. Would others find this feature
> > useful? Is such a feature already on the way? Are there other ways
> (besides
> > middleware) of getting these features that I'm too dense to have thought
> of?
> > :P
>
> The soi-disant drop-box database would be extremely useful!
>
> My workaround is to use two databases. The public database allows
> writes but is otherwise not used by the application. An external
> (NodeJS) monitor copies the documents to the private database, then
> scrubs them from the public. 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.
>
> --
> Iris Couch
>
Re: no 'writers' section in _security killing me
Posted by Jason Smith <jh...@iriscouch.com>.
On Mon, Jul 11, 2011 at 11:21 AM, Jonathan Geddes
<ge...@gmail.com> wrote:
> 1. User feedback. I'd love to just throw up
Often when I work with CouchDB I feel the same way.
> a simple couchapp with a
> database that anyone can write to, but only certain users (or a certain
> role) can read from. I can't do this currently because if a user can write
> to a given database, they can also read from that database.
This is the most highly-desired feature I know of. No doubt many
people are excited to hear your enthusiasm about working on this.
> 2. A sort of voting feature on an app where users should be able to cast
> their votes, but not see other users' votes. I can easily ensure that each
> user only gets one vote in the validation by making sure the _id on the vote
> document matches the user's id. Here I have the same problem as the previous
> example. But Also, I can't *really* constrain each user to just one vote
> because if the user can write to the database, then they are an admin and
> they can change the design doc such that it no longer limits them to one
> vote. Then they can vote arbitrarily many times.
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 love to see the writers section of _security implemented. In fact,
> I've been trying to find a way to contribute to CouchDB, and I might take a
> whack at implementing this feature myself. Would others find this feature
> useful? Is such a feature already on the way? Are there other ways (besides
> middleware) of getting these features that I'm too dense to have thought of?
> :P
The soi-disant drop-box database would be extremely useful!
My workaround is to use two databases. The public database allows
writes but is otherwise not used by the application. An external
(NodeJS) monitor copies the documents to the private database, then
scrubs them from the public. 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.
--
Iris Couch