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
Click here to report this message as spam:
https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1
