[Mailman-Developers] MemberAdaptor... trouble with API?

[Barry A. Warsaw]

>>>>> "SS" == Steve Spicklemire <steve@spvi.com> writes:

    SS> I've started poking around in mailman, trying to help out some
    SS> folks, and I've come across something I'm not sure how to
    SS> handle. I'd like to get Mailman working with LDAP, and the
    SS> first order of business is to simply allow folks to use their
    SS> LDAP passwords as an option when authenticating with
    SS> Mailman. Here was my first crack at it:

    [...code...]

    SS> I expected that all I needed to do was to replace
    SS> "authenticateMember' in extend.py and I would be
    SS> set. Unfortunately, my code never gets called! Snooping
    SS> through the SecurityManager class, I see that instead, it uses
    SS> 'getMemberPassword', and never calls 'authenticateMember' at
    SS> all!

Worse than that, a grep reveals that authenticateMember() isn't called
/anywhere/.

One of the reasons why SecurityManager is written the way it is, is
because we want to be able to use the password as part of the input
into the cookie hashcode.

    SS> The problem is that we don't have any unencrypted
    SS> passwords to "get".

Do you have an encrypted password, or any other secret only associated
with the member?

    SS> So do I need to override "Authenticate" of
    SS> SecurityManger to call authenticateMember rather then
    SS> 'getMemberPassword'? This seems a little wierd. Would it be
    SS> better to have SecurityManager call 'authenticateMember'?

There's a lot of code sharing going on here, between the part that
decodes the cookie and verifies the cookie or cleartext password
input.  You could try the following patch, untested, to see if this
helps.  I'll try it too when I get a chance.

    SS> Is
    SS> the cleartext password really required? If it *is* actually
    SS> required, couldn't the code just call 'authenticateMember',
    SS> and if successful, use 'response', rather than asking for the
    SS> cleartext password from the member adaptor?

Hmm, possibly!  MakeCookie() would have to change too, and
WebAuthenticate() would have to pass it teh response, which it would
use as the secret instead of what AuthContextInfo() returns.  You'd
still need to call AuthContextInfo() to build the key though.

You bring up some good points.
-Barry


-------------------- snip snip --------------------
Index: SecurityManager.py
===================================================================
RCS file: /cvsroot/mailman/mailman/Mailman/SecurityManager.py,v
retrieving revision 2.18
diff -u -r2.18 SecurityManager.py
--- SecurityManager.py	24 Jul 2002 14:24:45 -0000	2.18
+++ SecurityManager.py	20 Aug 2002 23:25:53 -0000
@@ -191,9 +191,7 @@
                 if secret and sha.new(response).hexdigest() == secret:
                     return ac
             elif ac == mm_cfg.AuthUser:
-                # The user's passwords are kept in plain text
-                key, secret = self.AuthContextInfo(ac, user)
-                if secret and response == secret:
+                if self.authenticateMember(user, response):
                     return ac
             else:
                 # What is this context???