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.