couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Branching 1.2.x
Date Fri, 16 Sep 2011 05:03:01 GMT
Currently you can add members to the

On Thu, Sep 15, 2011 at 8:16 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> 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:
>>>
>>> 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
http://jchrisa.net
http://couchbase.com

Mime
View raw message