On Mon, Jan 18, 2010 at 10:11:47AM -0800, Chris Anderson wrote:
> The reader ACLs are just a clone of the db-admin lists we've had for a
> long time. The goal is to do the simplest thing that could possibly
> work.
I disagree that it's the simplest thing that can work. IMO the simplest
thing would be to use regular docs, since all the infrastructure already
exists for those.
Can you explain why you appear to have discounted this option?
How about this for something really, really simple,
1. couchdb tests for the existence of a document with ID
"org.apache.couchdb.user:<username>"
or "org.apache.couchdb.role:<role>" [optional]
2. if this document is present, the user has read access. If it is not
present, the user has no access.
3. That's it, for now. (*)
These documents scale. These documents can be queried via views. These
documents can replicate. We can control how these documents are added and
removed by leveraging the existing update mechanism (validate_doc_update).
These documents could also store user prefs for the database instance.
These documents could also hold the 'security context' for
validate_doc_update as well.
So why not?
> As far as I can tell, the only case these reader ACLs + the planned
> security document can't handle gracefully is the case where the
> security document starts to get too large (in which case you can
> probably shrink it again by creating a new server-level role.)
No, that doesn't scale. Someone writes what turns out to be the next
Facebook and deploys it as db1 on your server. It manages its own roles
(i.e. users can sign up and it adds them as _readers to the database
itself). However if the _readers object becomes too big, you're saying
you'd have to grant a *server* level role of "facebook-user" to each user;
at this point, all new signups would have to be done by a process with
server-level privileges, which will be a real pain to implement.
I just don't buy this.
Regards,
Brian.
(*) Personally I'd also like to see 'roles' in these docs, and the roles
here merged with the system level roles. So in the _users db you could
grant a "_reader" role which would allow someone to read all dbs in the
system - useful for server-level first-line support. But you can also grant
"_reader" within the database itself. But that's taking it further than we
need to get the basic functionality we're talking about.
