couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Branching 1.2.x
Date Fri, 16 Sep 2011 09:37:07 GMT
COUCHDB-1060 is imminent, I pushed my integration work here A few things
to do before it should hit trunk.


On 16 September 2011 06:03, Chris Anderson <> wrote:
> Currently you can add members to the
> On Thu, Sep 15, 2011 at 8:16 PM, Benoit Chesneau <> wrote:
>> On Fri, Sep 16, 2011 at 2:59 AM, Chris Anderson <> wrote:
>>> On Mon, Sep 12, 2011 at 10:06 AM, Benoit Chesneau <>
>>>> On Mon, Sep 12, 2011 at 6:14 PM, Jan Lehnardt <> wrote:
>>>> I would like to put COUCHDB-431  in 1.2 , the last version is coming
>>>> later today. (I'm currentlly testing it)
>>> I agree cross domain XHR options would be useful. I haven't had a
>>> chance to dig in, but there does seem to be some question about the
>>> right way to implement. I'd be ok to save COUCHDB-431 for 1.3 as CORS
>>> is not a mainstream feature of the web (yet).
>> Questions *on the ticket* are addressed actually ... I  won't have
>> time to push it until next week but it will be on moday. So depending
>> ont the 1.2 timeframe, I would be for its inclusion. It doesn't break
>> anything and a lot of couchapp users are waiting such thing. It may be
>> not mainstream in some part of the industry, but CORS is the
>> technology widely deployed on the browser today. Even IE understand
>> that.
> Cool, sounds like it is ready. I agree w/ Randall of course CORS
> shouldn't be on by default. I just didn't want to add potential for
> delay. If CORS is ready lets backport to 1.2.x soon
>>>> I'm -1 for COUCHDB-1238. Since we are about to change the way we
>>>> handle the users, I think  it's better to wait for this one rather
>>>> than introducing another big dependancy on this user db.
>>> I don't think the user db is going anywhere, at least not in the 1.x
>>> timeframe. We are talking about ways to make it easier to work with
>>> and more secure, and I support that. Regardless, the COUCHDB-1238 is
>>> something that is useful to anyone using the user db and does not put
>>> a burden on folks who are not. For instance, I am building an app that
>>> uses this feature to connect your phone to the cloud, without the user
>>> ever having to specify a password.
>> Sorry but having oauth tokens in a db open for all is not as secure as
>> it is now, although it would be even worse (protecting access to a
>> configuration file is easy).  Not saying it  wouldn't be interresting
>> to have keys&tokens in a db. It is. But something like consumer keys
>> must be more protected than what offers this patch *by default*.  Imo
>> anything about authentication or security should have other arguments
>> than "it may be useful for". Especially when we know what can be the
>> issue.  We should first think on how to make it more secure.
> Hmm sure I think perhaps this oauth stuff should be turned off by
> default as well. The important thing is the flexibility. If your
> application is going to make use of these security features you should
> understand the implications.
> However oauth tokens are useful, and modeling user objects in a
> database make adding these kinds of features easy, as the scalability
> and management characteristics of databases are well understood.
> I think that with per doc _acl's the user db will become seamless.
> Each users's user doc is private to the user, and views are admin
> only, so it works great for our use case.
> Chris
> --
> Chris Anderson

View raw message