incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Geddes <geddes.jonat...@gmail.com>
Subject Re: no 'writers' section in _security killing me
Date Mon, 11 Jul 2011 05:17:28 GMT
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 <jhs@iriscouch.com> wrote:

> On Mon, Jul 11, 2011 at 11:21 AM, Jonathan Geddes
> <geddes.jonathan@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message