incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Updating the CouchDB roadmap
Date Sat, 19 Dec 2009 09:33:15 GMT
On Sat, Dec 19, 2009 at 9:08 AM, Chris Anderson <jchris@apache.org> wrote:
> On Fri, Dec 18, 2009 at 9:02 AM, Noah Slater <nslater@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/%3Ce282921e0911011048sec6a907xbeac06651ae2cd2c@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

Mime
View raw message