couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Cookie Auth
Date Sat, 11 Jul 2009 00:13:05 GMT
On Fri, Jul 10, 2009 at 4:50 PM, Mark Hammond<> wrote:
> On 11/07/2009 2:50 AM, Chris Anderson wrote:
>> One man's feature creep is another's requirement... I try to keep a
>> level head about CouchDB features by leaving out the ones that every
>> application will do differently. If we can make a session handler that
>> CouchApps all use by default, it will take an entire territory of pain
>> away from application developers. If we leave it out, everyone will
>> implement it differently and that starts to be it's own problem.
> I agree with the sentiment, but do wonder if this session handler really
> will be a handler everyone can use by default.  My experience with web based
> authentication has been that the biggest challenges are *integration* with
> existing auth schemes and concepts of 'session'. Integration directly with
> an external auth system (eg, NTLM), or with existing applications (eg,
> working with something like Zope's concept of security/roles) quickly means
> that one size rarely fits all in sophisticated environments.
> So while I don't question the utility of simple auth handlers (I agree many
> people will use them *first* while determining their real requirements or
> for simple environments), I still believe the focus should be on ensuring
> all the right hooks are in place so people can contribute or write handlers
> suited to a specific purpose, rather than trying to cover all these
> 'specific purposes' in a core module. Offering simple cookie or http-based
> auth scheme handlers as a 'sample' handler makes more sense and implicitly
> acknowledges we can't predict their specific use case.  Isn't that (from
> 1000 feet above) how Apache itself manages auth?  It is how IIS does.

I think we're on the right track as we're really using this
development to implement CouchDB's model of roles, which is
essentially an array of strings like: ["_admin", "foo", "bar"]

Having a working system which brings in more than just the admin role
is a big step forward in preparing to integrate with other auth
systems. The conventions about how to manage a directory of user
credentials etc are evolving and getting them into the release so we
can see how people use them is a big part of that.

> This is obviously just my opinion though - please take it for what it cost
> you ;)

Please keep them coming.


Chris Anderson

View raw message