On Fri, Sep 16, 2011 at 2:59 AM, Chris Anderson <[email protected]> wrote: > On Mon, Sep 12, 2011 at 10:06 AM, Benoit Chesneau <[email protected]> wrote: >> On Mon, Sep 12, 2011 at 6:14 PM, Jan Lehnardt <[email protected]> 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
