couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Branching 1.2.x
Date Fri, 16 Sep 2011 03:16:29 GMT
On Fri, Sep 16, 2011 at 2:59 AM, Chris Anderson <jchris@apache.org> wrote:
> On Mon, Sep 12, 2011 at 10:06 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> On Mon, Sep 12, 2011 at 6:14 PM, Jan Lehnardt <jan@apache.org> wrote:
>>>
>>> On Sep 12, 2011, at 18:07 , Noah Slater wrote:
>>>
>>>>
>>>> On 12 Sep 2011, at 16:35, Jan Lehnardt wrote:
>>>>
>>>>> The fact that we branch 1.2.x won't mean we can't get more tickets in
there, it's just to unblock trunk for post-1.2.x commits. I hope this makes sense and I hope
you all agree.
>>>>
>>>> How are we going to stop a repeat of the 1.0 release branch "kitchen sink"
problems?
>>>
>>> I'd like everybody to suggest their wish for 1.2.x and then agree with this group
on how much of the resulting list we can actually get into the branch in a reasonable amount
of time :)
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>>
>>
>> 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.

>>
>> 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.

- benoît

Mime
View raw message