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 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. 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. 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. 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. 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. Again, this is open-source, so scratch your own itch, feel free to write patches, argue about all this, etc. 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. Cheers, Chris -- Chris Anderson http://jchrisa.net http://couch.io
