RE: [Zope] LoginManager or exUserFolder
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|
+-------[ Mayers, Philip J ]---------------------- | What are membership services then? Basically a layer over the top of authentication and properties. Password parsing to make sure it conforms to some heuristic, allowing users to signup by themselves, change their own passwords, email them a new password, create 'home' directories et. al. | 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. The SQL Methods used are actually created inside the pgAuthSource Folder inside the acl_users. Should be pretty simple to do some sort of join, or alter the method inside pgAuthSource to fetch the roles seperately. You just have to munge the roles into a list before returning out of the authSource though. -- 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|
| 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.
The SQL Methods used are actually created inside the pgAuthSource Folder inside the acl_users. Should be pretty simple to do some sort of join, or alter the method inside pgAuthSource to fetch the roles seperately.
You just have to munge the roles into a list before returning out of the authSource though.
Hm... that'd be my next ask here at work. I am planning on building a new Generic SQL auth method that let's you specify what roles there are for a user using a one to many relationship model (actually a many to many relationship model). Also I want to break out the PostgreSQL dependencies, especially in the prop_source where both the field names and the table name are hardcoded in the python code. /dadrio
+-------[ Dario Lopez-Kästen ]---------------------- | | > You just have to munge the roles into a list before returning out of the | > authSource though. | | Hm... that'd be my next ask here at work. I am planning on building a new | Generic SQL auth method that let's you specify what roles there are for a | user using a one to many relationship model (actually a many to many | relationship model). Yes the current pgAuth is a fairly naive implementation, but still serves about 95% of population. The rest probably have the skills to build their own, which is the point of it really d8) It's also probably base/apex, there should be a roles table that maps a role to a user, rather than storing a list of roles with each user. You can't easily delete a role from the system (not that this would be a common operation), and have the changes propogate cleanly. The problem is keeping it simple enough out of the box, that relative newcomers can use it. Trying to explain even more than simple schemas can be somewhat difficult at times. People understand having one table with everything in it almost immediately. I have toyed with the idea of also having pluggable Roles sources, since some (especially remote) AuthAdapters can't natively provide this, and so there's a gross hack in things like etcAuthSource where roles are stored as a private property of the user. Whilst this is great for showing off the flexibility, it still leaves a bad taste in my mouth when I think about it. | Also I want to break out the PostgreSQL dependencies, especially in the | prop_source where both the field names and the table name are hardcoded in | the python code. Having a better schema probably wouldn't hurt here either d;) -- 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|
+-------[ Dario Lopez-Kästen ]---------------------- [...] | | Hm... that'd be my next ask here at work. I am planning on building a new | Generic SQL auth method that let's you specify what roles there are for a | user using a one to many relationship model (actually a many to many | relationship model).
[...]
The problem is keeping it simple enough out of the box, that relative newcomers can use it. Trying to explain even more than simple schemas can be somewhat difficult at times. People understand having one table with everything in it almost immediately.
yeah, that's the hard part. I was thinking of maybe using Gadfly as an example along with a schematic drawing of why you'd want to do it this or the other way.
I have toyed with the idea of also having pluggable Roles sources, since some (especially remote) AuthAdapters can't natively provide this, and so there's a gross hack in things like etcAuthSource where roles are stored as a private property of the user.
hm... this would really be a nice idea I think being more modular... seems like we are thinking in the same patterns here, perhaps? I've written up a bit on user management for some internal infrastructure work we are doing, where we have identified the "services" we need to have in order to manage users and accounts and people. You can find it here http://www.zope.org/Members/dlkita/user_management if you have the time to spend, i'd appreciate your comments. What I want to do is to use Zope to provide the GUI to manage the infrastructure and as well as fetch the sources for Zope's users _from_ the infrastructure. So far it seems that XUF is a perfect fit for it, given a little more development and testing. An excellent proof of this is Philip Mayers PAM auth recipe, which is something I'll look into (it solves on big problem for me: kerberos/dce auth :-) Thanks, /dario
participants (3)
-
Andrew Kenneth Milton -
Dario Lopez-Kästen -
Mayers, Philip J