incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: no 'writers' section in _security killing me
Date Mon, 11 Jul 2011 04:49:31 GMT
On Mon, Jul 11, 2011 at 11:21 AM, Jonathan Geddes
<> 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

View raw message