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 "[email protected]" as well as "[email protected]" 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 "[email protected] ; [email protected]" - 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 userCtx.name would be an object {"[email protected]":true,"[email protected]": true} instead of a simple string - I would then check for "[email protected]" in userCtx.name or userCtx.name["[email protected]"] to find out whether the current user has access to a specific doc. Sure, I could assign userCtx.name 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 userCtx.name (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 userCtx.name 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 .roles? regards, Joscha --
