couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
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
https://github.com/rnewson/couchdb/tree/integrate_pbkdf2. A few things
to do before it should hit trunk.

B.

On 16 September 2011 06:03, Chris Anderson <jchris@apache.org> wrote:
> 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