-----Original Message----- From: Kyler B. Laird [laird@ecn.purdue.edu]
On Wed, 2 Aug 2000 15:13:45 -0400 you wrote:
I've gotten it working with Postgres (with crypted passwords no less!) It took me a couple of weeks on and off to finally get that going. Yes, it was painful, especially having no prior experience with GUF (or much experience with Zope, for that matter...) I've not made it a very high priority, but I'm working on a LoginManager/PostgreSQL walkthrough hoping that I might save someone else some grief. That info should be easy to translate for any other datasource full of users you might have in mind. Interested?
What I read: "I see you're starving. Are you interested in some food?"
Well, probably more like, "Are you interested in Spam and CheezWiz on saltines?" ;-)
Yes! I'm desperate for a way to use Oracle and/or X.500 databases for authentication (and authorization and ...). I would be happy to pay someone to hold my hand through creating such a product. (This is one of the first things I built into Apache so many years ago.)
LM is a fantastically versatile product, which also makes it a potentially major PITA. Not having sufficient documentation makes it a recipe for insanity. (Save yourself, it's too late for me!)
I'm a bit fuzzy on this, though. Shouldn't there be an easy way to generalize databases for this purpose? Why do we need PostgreSQL, Oracle, Gadfly, ... versions? I'd like to be able to just choose a connection ID and go.
The gist of it is this: First you create (or use the default) UserSource. It's basically an empty box that is used to contain the various methods used to authenticate a user. You can have more than one UserSource, meaning you could have US's validating against SMB, LDAP, UNIX passwd, NIS, etc. (i.e., pretty much anything that Python will talk to) all running in conjunction. If validation fails against the first US, LM will simply drop through to the next and so on, until it either validates the user successfully, or drops out the bottom and denies access. You will first need to create a method for determining if a user exists. If the user exists, return 1, otherwise 0. A second method is required to take the entered username and actually look up a password, validate it against the password entered by the user and return success (1) or failure (0). A third method is used to look up the user's roles and return them as a list. These roles should match up against either default Zope roles, or preferably roles you've created for the purpose. You then lock down permissions on the desired folders/objects so that only users with the correct roles can access those objects. And lastly, a forth method is needed to return a list of valid net domains from which the user is allowed to log in. If you don't want to restrict logins by domain, then simply return an empty list. So, regarding your question about why should it matter which database, it doesn't. Not much anyways. US covers a much broader spectrum than just databases. As I indicated above, pretty much anything you could conceive of to store user data in, LM can interface to it. For some US's you may need to craft one or more external methods in Python. If it's a DBMS like Postgres, Oracle, MySQL, MSSQL, you will need a database connection method, and you will need SQL methods to fulfill the above four validation steps. Which brand of database you connect to is likely only going to affect minor issues of SQL syntax within your methods, if that. The way your user data is *structured* will have more impact than which database you use. That leaves out a ton of detail, but should hopefully answer your immediate questions and then some. Feel free to drop me a note at cwilkins@boinklabs.com and we can further discuss getting your LM up and running. -cw-