On Sat, Dec 19, 2009 at 9:08 AM, Chris Anderson <jch...@apache.org> wrote: > On Fri, Dec 18, 2009 at 9:02 AM, Noah Slater <nsla...@tumbolia.org> wrote: >> >> On 18 Dec 2009, at 16:45, Dirkjan Ochtman wrote: >> >>> That said, it's perfectly alright if there's no roadmap at all, I'm >>> just surprised by the lack of thoughts from the core developers (who >>> are usually the ones to have these ideas) in this thread. >> >> Three of the core developers have been busy attending to real life for the >> last few weeks. :) > > Heh, > > Mostly I've been dealing with real life by buckling down and writing code. > > I wrote up my ideas for 0.11 / 1.0 in this thread Nov 1st: > > http://mail-archives.apache.org/mod_mbox/couchdb-dev/200911.mbox/%3ce282921e0911011048sec6a907xbeac06651ae2c...@mail.gmail.com%3e > > Re-reading it they are still features I'm interested in, although I'm > much less ambitious now. What I'd really like to see for 0.11: > > Account's tab for Futon: > There's no reason app developers should have to write user account > code or login/logout code. Users should just be able to log in and out > of CouchDB (and sign up for accounts) via something like a Futon page > that ships with the db. The userCtx is already available to Ajax apps > via /_session so once we have a reliable way to log in and out this > will be useful. > Maybe we could also make the auth really useful when you don't access to CouchDB behind a proxy. My plan about this is :
- having authentification a little more modular than it is : cascading across authentification modules and also add authentification via a script - authorization: having a way to protect read/write(so delete too) on a db for a list of users or roles - Protect access to the user database. Having it readable by public isn't good for security purpose. Regardless of the length of the key or the algorithm used, there will be a time where it isn't enough. Imo we should hide access to this db behind an api. > Design Doc Refactor: > I've been heads down working on this patch in my spare time for the > last 3 weeks. It is 90% a pure refactor (cleanup code not add new > features.) It is nearing completion. This will change the query server > protocol but not the HTTP API. You can look at what I've got here: > http://github.com/jchris/couchdb/tree/ddoc-qs What will be the changes in protocol ? > > Query Server Security: > I haven't started on this yet but my plan is just to work from > http://github.com/rcoder/couchdb/commits/master to make it more clear > when the curl bindings are available to the JS sandbox. If anyone will > pick this up and run with it I will jump for joy. > I failed to find the relation with security :) Isn't the point of this fork to add an http client ? - benoit
