From dev-return-2794-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri Feb 20 23:39:36 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 14064 invoked from network); 20 Feb 2009 23:39:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Feb 2009 23:39:36 -0000 Received: (qmail 98156 invoked by uid 500); 20 Feb 2009 23:39:36 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 98117 invoked by uid 500); 20 Feb 2009 23:39:35 -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 98106 invoked by uid 99); 20 Feb 2009 23:39:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2009 15:39:35 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2009 23:39:25 +0000 Received: from [10.0.1.6] (e178236252.adsl.alicedsl.de [::ffff:85.178.236.252]) (AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by jan.prima.de with esmtp; Fri, 20 Feb 2009 23:39:04 +0000 Message-Id: <190CB078-653A-470B-8EAD-143642B81A1C@apache.org> From: Jan Lehnardt To: dev@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: User Auth Date: Sat, 21 Feb 2009 00:38:31 +0100 References: X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org Hi Stefan, good to have you o board, On 21 Feb 2009, at 00:16, Stefan Karpinski wrote: > > I think that nailing this problem would go a *long* way towards making > CouchDB popular not only for it's nice distributed properties and > such, but also because would make writing modern web apps drastically > easier. Because literally *every* non-trivial web application needs to > do user authentication. Having it _just work_ without having to worry > about it is a massive win. Moreover, if the database was actually > aware of application-level authentication and could enforce it, then > it would increase the security of CouchDB-based web apps. Errors in > business logic would be much less likely to accidentally expose data. > How easy is it to forget in Rails that you need to filter the objects > in some table by the user_id field? My thoughts* exactly! * http://markmail.org/message/thqtiuz3a5hr2ngd Cheers Jan -- > On Fri, Feb 20, 2009 at 3:01 PM, Chris Anderson > wrote: >> >> On Fri, Feb 20, 2009 at 1:51 PM, Stefan Karpinski >> wrote: >>> I'm not entirely clear what level of user auth is being addressed >>> here. >>> >>> On the one hand, there's the system-level sense of a user that >>> traditional >>> databases have: i.e. something equivalent to a UNIX user account, >>> but in the >>> database, which has to be created by an admin and can then be >>> granted >>> table-level access and various administrative rights (create user, >>> create >>> database, create table). >>> >>> On the other hand, there's the application-level sense of user: >>> i.e. a >>> record in a users table, which is given access or not given access >>> to >>> database records via the web application stack at a higher level, >>> which sits >>> between the database and the client's web browser (or whatever). >>> >>> The current CouchDB notion of admin user seems to fall into the >>> former >>> category, while what most applications need falls into the latter >>> category. >>> One irritation of all application-level authentication schemes >>> I've ever >>> encountered is that the database does not give you any support for >>> application-level user auth. If CouchApps are really going to be >>> feasible, >>> CouchDB (clearly) needs to solve the application-level user >>> authentication >>> problem. >>> >>> My sense is that the goal is to somehow merge the two senses of >>> database >>> user, and thereby cleave the Gordian knot in two. Is that sense >>> correct? >> >> I wish I could say we've got such a clear picture of it. >> >> The easiest way to cleave the knot is probably to rely on 3rd party >> auth like OpenID or OAuth (I don't quite know which parts of which >> we're interested in). >> >> Identifying users as URLs would make things easier on application >> devs, I think. >> >> If every app will need to implement something like this, it makes >> sense to me to have the CouchDB host manage the session, even if apps >> can keep their own user-preferences docs if they wish. Being logged >> into all the apps on a node seems a lot more intuitive than having to >> create accounts for each one. If the user is identified with a URL, >> then preferences etc can be replicated to other hosts while >> everything >> "just works". >> >> Thanks for the feedback! >> >> -- >> Chris Anderson >> http://jchris.mfdz.com >