From dev-return-22911-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sat Aug 25 09:55:24 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 45D3DD281 for ; Sat, 25 Aug 2012 09:55:24 +0000 (UTC) Received: (qmail 46096 invoked by uid 500); 25 Aug 2012 09:55:23 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 45539 invoked by uid 500); 25 Aug 2012 09:55:16 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 45480 invoked by uid 99); 25 Aug 2012 09:55:14 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Aug 2012 09:55:14 +0000 Received: from localhost (HELO [192.168.1.5]) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Aug 2012 09:55:13 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) Subject: Re: Merge in new authentication code From: Robert Newson In-Reply-To: Date: Sat, 25 Aug 2012 10:55:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2955AE2C-1DD7-42BC-950F-EA492C6E8647@apache.org> References: To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1278) I have no objection to these landing in master. We discussed, in Dublin, = a plan to turn out releases more regularly and predictably. To Benoit's = point, I would say that if we did so (and turned out a release, however = minor, every couple of months) that these can go in. Further, it's = typical, in the event of a security-impacting bug, to backport those = fixes anyway, the kind of thing the Debian's and Ubuntu's of the world = do for many projects. B. On 25 Aug 2012, at 09:46, Benoit Chesneau wrote: > On Aug 25, 2012 3:27 AM, "Jason Smith" wrote: >>=20 >> Hi, developers. >>=20 >> At Iris Couch, we have used two third-party CouchDB extensions for a >> very long time. I would like to merge both of them into master. They >> provide alternative ways to create a CouchDB user and to log in to >> CouchDB. >>=20 >> Both mechanisms use a third-party authenticator which basically tells >> CouchDB that the person is who they say they are. Both mechanisms = then >> create a local CouchDB _users document. So you can set a .password >> value and have both types of authentication. >>=20 >> ## Mozilla Persona >>=20 >> Written by Randall, used in production here for a year. This is >> hands-down the easiest way for developers to add logins to their = Couch >> apps. See https://github.com/iriscouch/browserid_couchdb#so-simple >>=20 >> ## CouchDB-XO_Auth >>=20 >> Created by Ocasta, this is basically a general OAuth implementation. >> It already works against Facebook and I am now making sure it works >> with GitHub too. It has the same autovivication feature for >> newly-authenticated users. >=20 > These extensions are nice but I don't think they should be part of the > couchdb distribution. >=20 > In my opinion we should keep the couchdb simple and only target core > features which are imo Document oriented, Views, CouchApps . = (couchapps > and views could be also considered as core features extensions). = Which > doesn't mean we shouldn't support new addons, and for me the best way = to > do that is to ease their installation and management in couch and > provide tools to make your own distribution. >=20 > Also, adding these addons in couch will slow down the development of = such > extensions. Fix would only happen when couch is released which is imo > bad. Especially for the 2 extensions you mention since theyr are = moving > target (persona is not yet a stable protocol nor widely used and the > other connect to proprietary oauth extensions which can be changed = ahen > the commercial entity want). Keeping them out the core distribution is > better for them. >=20 > Maybe as sub-projects? Not sure it worth the admin stuff. >=20 > - benoit