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) <
[email protected]> wrote:
Sorry I phrased that badly.
Back in the days of Lotus Notes it was possible to have users who
were able
to write into, but not read from a database. Is similar
functionality built
in to CouchDB or must it be enabled by external logic?
as
On 12/07/2011, at 7:48 AM, Robert Newson wrote:
how would one replicate these write-only dropboxes?
B.
On 11 July 2011 22:13, Andrew Stuart (SuperCoders)
<andrew.stuart@supercoders.**com.au
<[email protected]>>
wrote:
I've followed this thread but it's still somewhat unclear -
-- is "write only" database access built in/easy to do, or must it be
enabled via some special external logic imposed at the application
layer?
as
On 12/07/2011, at 6:39 AM, Jonathan Geddes wrote:
One more possible solution: Could I use the rewriter to make sure
that
that
only POST and PUT go through to a given database? How secure is this
approach?
--Jonathan
On Mon, Jul 11, 2011 at 8:45 AM, Jonathan Geddes
<[email protected]>**wrote:
Thanks for the responses, everyone.
So I've been using CouchDB for about a year, but I'm only now
getting
into
the "2.1 Layer Architecture" (cutting back from a 3+ layer).
Apparently I've been using readers and admins wrong all along. I
thought
that only admins could write documents. After all, why would I
think that
'readers' could write? I've been a victim of the misnomer!
I still think that the dropbox feature would be immensely useful,
and I
still might take a whack at implementing it.
Thanks for the clarification,
--Jonathan
On Mon, Jul 11, 2011 at 1:17 AM, Jason Smith <[email protected]>
wrote:
On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
<[email protected]> wrote:
Fortunately, users with write access are not admins. They may not
modify design documents. All of their changes are subject to
design
documents' validate_doc_update() function.
I would be *overjoyed* to hear that you are right and the
documentation
at
[0] is wrong:
database admins - Defined per database. They have all the
privileges
readers have plus the privileges: write (and edit) design
documents,
add/remove database admins and readers, set the database revisions
limit
(/somedb/_revs_limit API) and execute temporary views against the
database
(/somedb/_temp_view API). They can not create a database and
neither
delete
a database.
D'oh, Marcello posted a pithy and timely answer while I had lunch.
I'll send anyway.
The typical setup is:
* 1 server admin
* 0 or more database admins (name or roles in _security.admins)
* An admin deploys a design document
* Several normal users (name or roles in _security.readers but
*not*
admins)
"readers" is a misnomer. It really means "members." Read access is
database-wide, write access is at the pleasure of
validate_doc_update().
To that end, Chris changed CouchDB so that future releases will use
the "members" field. He committed his change last Thanksgiving
weekend. Thanks, Chris!
I'm gonna set up a little experiment in the morning (when I can
think
clearly) to find out for myself. The _revs_limit PI and
temporary views
are
scary too.
I strongly encourage an experiment. 15 or 20 minutes of poking
around
will make things very clear.
Cloudant has a brilliant UI to impose more intuitive and
traditional
security policies for exactly this reason.
I call it a 2.5-layer architecture
because there is no middleware, but it still requires a third
component, to watch over things. The drop box would be amazing;
however I am still happy with my architecture because bugs or
crashes
in the third component are not so devastating to the user
experience.
The great thing about this architecture is that you can easily
have
CouchDB
monitor the third party stuff and keep it running with external OS
processes
[1]. I like the term '2.5-layer' :D.
Is it too late to change the name to "2.1-layer"?
* Hints that the extra step is not going to break your back
* Kind of like 5.1 surround sound
By the way, why hasn't this been implimented before? It seems
strange
to
me.
Is there something inherent in the architecture of CouchDB that
makes
this
difficult?
I think it is a matter of time. The people in a position to
implement
it have not felt quite enough pressure.
/me whistles innocently.
--
Iris Couch
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and
content
filtering.http://www.**mailguard.com.au/mg<http://www.mailguard.com.au/mg
>
Click here to report this message as spam:
https://login.mailguard.com.**au/report/1CGUOUsAWN/**
2BVxdPfDhfeJK4SLOnz0gl/1<https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1
>
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and
content
filtering.http://www.**mailguard.com.au/mg<http://www.mailguard.com.au/mg
>
Click here to report this message as spam:
https://login.mailguard.com.**au/report/1CGW2fhE4N/**
5SE2wTOEjJss04ObshZ4q9/1<https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1
>
