couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <>
Subject Re: Per-DB Auth Ideas and Proposal
Date Tue, 15 Sep 2009 14:02:21 GMT

On Sep 14, 2009, at 4:33 PM, Jason Davies wrote:

> On 14 Sep 2009, at 06:12, Chris Anderson wrote:
>> Heh - the easiest programming model for security is to forgo
>> server-side views altogether, so that client interact with the server
>> through replication.
>> Then you could handle read security with a server-enforced _filter
>> function during replication. You'd program security rules into the
>> filter function, and it could eg: make sure players can only see
>> playbooks for their own team, but that referees can see all  
>> playbooks.
>> The client can replicate whatever they are allowed to see, and build
>> any views they can think of, without compromising security. Not to
>> mention all the computation saved on the server-side for building
>> views for each user.
>> (I'm well aware that a programming model like this presupposes a
>> personal CouchDB capable of bidirectional replication and local view
>> generation. But doesn't that sound relaxing?)
>> With a _filter function based security model, implementing deny
>> semantics (Joan's surprise party) gets a bit easier, too. If we can
>> make it work from a concurrency perspective than I'd be all for it.
>> Maybe we just need to require the _filter function be written in
>> Erlang. Oh and that clients generate their own views. ;)
> Sounds good but if the performance is akin to running _list over all  
> the docs it could be quite slow for a gazillion docs, or am I  
> missing something?

Okay, my turn to go "huh"

In many cases the last thing that you'd want to have the client to  
have is the raw data.  You'd generally want to use views to aggregate  
or filter the underlying data so that the client only sees the data  
that you intend them to see.

View raw message