On Wed, 08 Aug 2001, Kevin J. Menard, Jr. spewed into the ether:
<snip>
> Ok, so you did get it. Like I said, mostly just a port of the SASL patch
> over, and it worked fine for me. Btw, I'll be releasing a newer version of
> the SASL LDAP patch later today. Fixes a free() issue and removes the
> default filter.
Good then.
> DB> If I may make a design suggestion, why not have authenticaion totally
> DB> configurable? Let cmd_authenticate() take a parameter from the config
> DB> file which specifies the login method.
<snip>
> DB> This will make it easier to add modules for authenticating from any
> DB> type of database.
> DB> Does this concept of a factory type of function make sense?
> I still say add all this to SASL. That's what it's there for anyway, so you
> don't need to hack imapd.c or pop3d.c everytime you want to add a new auth
> method. What I would like to see, is a way to dynamically add auth methods
> to SASL.
Nope. I might want to store user data in SQL/LDAP/plain
text/sasldb/some other wierd place. You don't need to hack imapd.c or
pop3d.c. I'm suggesting a PAM like system. Hell, I wonder if pam_sasl
could be used instead of sasl directly. PAM is supposed to do exactly
this, right? Since all that we are doing is calling a specific set of
functions, the interface is standard. Just put in appropriate hooks
into the modules, and we are done. Let the module handle the complexity
of non-plain text passwords.
This sounds even better than my original idea. Anyone with a better
idea?
Devdas Bhagat
