On Sep 13, 2009, at 2:07 AM, Chris Anderson wrote:
What are the next steps?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
Whatever name we choose, I think it should certainly be an underscore- prefixed reserved name. I'm partial to _acl myself.
I played around with read & write access lists but write can be handled by the validation function so it's not necessary. The only reason we have to standardize this stuff at all is to avoid a Spidermonkey call on read, so we can keep it as simple as possible.
I think we should implement both read and write restrictions using these ACLs. Both for performance reasons and because it'd be weird if reader and writer lists were configured in such different fashions.
If calling out to Spidermonkey on reads isn't as awful of a performance hit as I expect it to be then supporting Vlad's validate_doc_read proposal would also make sense from symmetry arguments.
I also thought about adding allow/deny so that eg, everyone but Joan could see Joan's surprise party invitation. But that seems to wreck havoc with any kind of sane way to make security work with views.
Can you say a little more about this? How are you envisioning view security working with per-document controls? 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.
The other option is to require views be calculated on the client, which means you can punt on view security, and just let read-security handle it during replication.
Huh? Best, Adam
