couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joscha Feth" <>
Subject Re: authentication cleanup
Date Mon, 28 Dec 2009 11:39:55 GMT
Chris Anderson wrote:

> I'm attempting to make more sense of CouchDB's authentication system.
> The current system is a proverbial ball of spaghetti. I'm still in the
> investigation stage of my work, and I'm writing this to clarify my
> thoughts and solicit feedback.

Hi Chris,

It's maybe not the ideal place to discuss this, but when using LDAP as
authentication mechanism within a reverse proxy, I noticed, that the
username (we have a large userbase, and users may have different eMail
addresses) to be used to login might differ from time to time, so the
user might "" as well as "" to login, but its still the
same user.
For LDAP this is no problem, but I am setting a special header which
gets sent to CouchDB afterwards, if the user has successfully
authenticated. This header will contain both email addresses separated
(this "list" is coming from LDAP) - which is " ;" - now
I wanted to write a special authentication module, which can read this
header and distribute it to the userCtx - but the thing is, I have got
two possible user names, so ideally would be an object
{"":true,"": true} instead of a simple string - I would
then check for

"" in or[""]

to find out whether the current user has access to a specific doc.
Sure, I could assign the combined string and search with
.indexOf, but I am just a little worried that there might be some
built-in logic within CouchDB which makes a some assumptions about (for example comparing it by ==), which would then break
my scenario in a later version of CouchDB.

Did you think of maybe provide a hook-point for users to do a
comparison for documents against userCtx? Something which could just
use == for .name in the default implementation, but which can be
changed using a design doc or a hook within local.ini? Then maybe can be loosened to not only be a string.
Another question I didn't find anything about in the docs: is it
intended to store additional properties within userCtx beside .name and



View raw message