couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: User Auth
Date Fri, 20 Feb 2009 23:38:31 GMT
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 <jchris@apache.org>  
> wrote:
>>
>> On Fri, Feb 20, 2009 at 1:51 PM, Stefan Karpinski
>> <stefan.karpinski@gmail.com> 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
>


Mime
View raw message