On Tue, Feb 9, 2010 at 11:52 PM, Chris Anderson <jch...@apache.org> wrote: > Devs, > > I've been getting a lot of feedback about the authentication & > authorization work that I did over the holidays and over the last few > weeks. There are also some enhancements I've been thinking about for a > while. Here's a quick list of what I see as the important things to > do. I'm not concerned here with releases / feature freeze etc as in my > opinion CouchDB development is expected to continue even after we > reach 1.0. > > 1) Extensible password storage. > > Thanks Brian Candler for the links to the OpenLDAP style of storage. I > think we should do this asap so we don't have to worry about backwards > compatibility with the current storage mechanism until the end of > time. The relevant message: > http://permalink.gmane.org/gmane.comp.db.couchdb.devel/7588 +1
> > 2) ACLs / Security Object > > I couldn't originally think of a reason the validation funs would need > to see the per-db admins / readers lists. Brian has a use case for > this. Also, I think I can accomplish this feature while also > simplifying the implementation. I'd like to make it so each db has an > /_security object that contains admins and readers (in their current > form, but as fields on the object, not as separate object at different > URLs). This entire object would be made available to the validation > functions. I've read all the thread, and I'm not conviced all readers and admins should be in one doc. List could be long also it would require to check if one already exists some stuff like it. Why not putting all in their docs and making a view on it ? > > 3) More system roles. > > Brian also mentioned something about _user and _anon roles which could > be applied to the userCtx automatically. This would be handy in both > per-db access control and in validation functions. This will be a bit > harder to implement as it touches more of the codebase. I'm also > uneasy about these roles as they raise the burden for implementors of > pluggable authentication modules. Everyone could be _anon instead of _admin though. > > Going forward we maybe want to add a _replicator role (or maybe that's > a horrible idea). We should also think about making it possible for > _admins to interact with the database without the _admin role. They > could trigger admin actions with something like sudo. I want to put > this off for now, because it's complicated and worse-case scenario is > people don't realize they need to "sudo" to get things done, and come > away thinking CouchDB is fighting with them. Just to be sure everything is one user db ? Just want to make sure it's possible to replicate all authentification for a node or even a cluster. > > 4) _temp_views and _all_dbs (maybe more) > > Regardless of whether the above is done, for 1.0 we should clean up > any bugs like these. > > 5) drop box > > If we had the concept of DBs that you could write to but not read > from, it would make read-controlled _users dbs compatible with new > user signups. This would be not that fun to implement, but potentially > useful for lots of other things too. > +1 on this. > > I hope this clears things up for people. The only other thing I feel > compelled to add is that CouchDB has never had (and probably never > will have) any concept of per-document read control. It is too fraught > with pitfalls, and even the best ideas about how to enforce > per-document read-control put an unacceptable burden on implementors > of alternate view engines. also it's already possible to do such auth via _show. Someone could put a role member in a doc and even user list and check it. but only show should be public in this case. > > Again, this is open-source, so scratch your own itch, feel free to > write patches, argue about all this, etc. > Maybe we could move all the work in its own branch ? > That said, if nothing but #4 ever gets done I'd still be proud of the > system as it stands today, as I think it's more or less the simplest > thing that could possibly work. > I was thinking we could open a wiki about it to describe how it works in detail and what could be changed later ? Could help for developer of current apps that would require a pure couchdb auth system. Thanks for all these details :) - benoit
