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.
