Michael Bernstein wrote:
>  
>  Michael Bernstein wrote:
>  >
>  > I figured out how to get this to work (finally).
>  >
>  > In the acl_users LM, add the following two Python methods:
>  
>  Well, I discovered another problem:
>  
>  For some reason, when I create a PortalMembership member, add the two
>  Python methods as I described earlier, and use the local roles screen to
>  give them a role, they are subsequently authenticated regardless of
>  whether their password is correct.
>  
>  Here's an example illustrating the bug:
>  
>  [snip example]

This password problem is fixed with Bill Andersons new
release of Membership 0.7.6, so the local roles fix now
works generally.

There is still a platform dependent password problem with
Membership though. It affects Solaris and HPUX (possibly
other unices) but not Linux, and has to do with the crypt
module not being loaded correctly on those platforms,
causing passwords to be encrypted omly part of the time.

Here is the fix for local roles:

First, the User Source needs to support a getUserNames
method. This can be done two ways:

You can add a Python method to the LoginManager named
getUserNames that takes a 'self' parameter, and has the
following body:

 user_ids=self.UserSource.getPersistentItemIDs()

 names=[]
 for i in user_ids:
     names.append(i)
 return names

Or you can add the following code directly to the
PersistentUserSource.py file, preferably right befor or
after the getUsers method:

    def getUserNames(self):
        user_ids=self.getPersistentItemIDs()
        names=[]
        for i in user_ids:
            names.append(i)
        return names

(I hope this will get included in future versions of
Membership)

Next we need to provide a user_names method in the
LoginManager. Currently I only have a Python method to drop
in to the LM. it takes a 'self' parameter, and has the
following body if it's calling another Python method:

return self.getUserNames()

Or if you're calling the method in PersistentUserSource.py,
it has this body:

return self.UserSource.getUserNames()

Note that this user_names method has some disadvantages, and
it needs to be generalized to deal with multiple User
Sources that aren't all named UserSource, and that may not
all implement the getUserNames interface, and that may have
duplicate user names in them.

Suggestions on how to do this would be welcome.

I hope that this little set of instructions helps others who
are trying to integrate LM with the existing security
interface and local roles.

Comments, testing, and improvements would be welcomed.

HTH,

Michael Bernstein.