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 <[email protected]> wrote: > Currently you can add members to the > > On Thu, Sep 15, 2011 at 8:16 PM, Benoit Chesneau <[email protected]> wrote: >> 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: >>>> >>>> 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 >
