What are membership services then? Regarding the remote method - Duh! Yes, of course (brain spasm - obviously the word remote threw me off the scent...) One other thing I did run into is that roles in my user source are a separate table with a foreign key back to the username, rather than space-separated as a column in the user table - for that reason, the default SQL user source wouldn't work for me (since as it happens I do store the crypt in the table at the moment - so near and yet so far). I probably could have done a fiendish CREATE VIEW... but I had about ten minutes of downtime to get the site from 2.3 to 2.4.1! I'll take a look at it again in a test setup. Thanks for the reply - it's always reassuring to know that a product is being actively pursued and maintained! Regards, Phil +------------------------------------------+ | Phil Mayers | | Network & Infrastructure Group | | Information & Communication Technologies | | Imperial College | +------------------------------------------+ -----Original Message----- From: Andrew Kenneth Milton [mailto:akm@theinternet.com.au] Sent: 24 September 2001 12:23 To: Mayers, Philip J Cc: 'Andrew Kenneth Milton'; 'zope@zope.org' Subject: Re: [Zope] LoginManager or exUserFolder +-------[ Mayers, Philip J ]---------------------- | For the CMF? Irrelevant for me. No, it is completely independant of CMF. | What I really have a problem with is the structure of the default/example | methods return a crypted password into Zope, whereas my LoginManager has a | userAuthenticate call that jumps into an external method and uses PAM to | check the password. Each authentication source can define a remoteAuthMethod method that is called with the username and the password provided by the user. You can then do whatever you want with it from that point on. This is how the IMAP and POP3 authentication methods that mithro wrote work, (http://www.zope.org/Members/mithro/zExtraExAuths). exUserFolder is setup in such a way that these can be seperate products, so you don't have to work in the exUserFolder source tree, and you don't have to install them into the exUserFolder tree for them to work. The User object specifically checks for remoteAuthMethod in the currentAuthSource and uses that instead of trying to authenticate using the supplied crypt method. For usAuthSource which is the one extendible by creating your own methods inside Zope, this is commented out by default. It's a simple matter of editing usAuthSource.py, uncommenting the region, and defining usRemoteAuthMethod, in your set of methods which can be an external method, or a pythonScript, or any other callable Zope object. I don't see how you can claim that it's a lot of work, it doesn't seem to be any more work than providing a method for LoginManager. Don't get me wrong, I'm not trying to shove XUF down your throat, I'm just concerned you have the wrong idea. If you think it would work better another way, I'm all ears, after all that's how the Remote Authentication Facilities got in there in the first place. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|