couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Per-DB Auth Ideas and Proposal
Date Tue, 15 Sep 2009 08:56:02 GMT
On Sun, Sep 13, 2009 at 08:33:25PM -0400, Adam Kocoloski wrote:
>> I think a per-doc reader ACL is a fine place to start.
>>
>> If a doc has an element like
>> {
>> "_id":"football playbook",
>> "_rev":"2-a24d12b",
>> "access" : {
>>    "roles" : ["players"],
>>    "users" : ["coach"]
>>  },
>> }
>>
>> or maybe "access" isn't the best name, but the idea should be clear  
>> enough
...
> It seems to me that once  
> you have per-doc ACLs view security is already complicated, and you  
> might as well go all the way to allow/deny support too.

Thinking aloud: if views could emit acls, then you could explicitly decide
in your view who can see each row, e.g.

  emit(key, value, acl);

However I can see this could lead to awkward performance problems:

(1) doing a fetch across a key range where millions of rows are invisible to
you because of the acls - server would have to skip over these one by one.

(2) we surely don't want to recalculate the reduce function based on which
view rows are visible to the end user or not.

So actually, I think this would break incremental map/reduce completely,
which for me is CouchDB's biggest and best feature.

I believe a more scalable solution would be to write N versions of the view,
one for each of the N different roles your application has, and then
restrict access to each entire view based on the role. Each view would have
to filter appropriately. Or, each view could be generated within the
"context" of a particular role: by this, I mean that the view would only be
fed documents accessible to that role.

Having said all that, I'm unlikely to use per-doc ACL functionality myself,
and so would rather see it as some sort of optional stackable layer on top
of CouchDB.

I suppose I might end up using database-level access controls, as this would
give me the option of exposing the database directly to the end-user as a
sort of bare-metal JSON API, but to be honest I think I'd still prefer to
keep a middleware layer to control this, since I'm keeping the HTML one
anyway (my app logic is too complex for just _show and _list)

Regards,

Brian.

Mime
View raw message