From: JT S. <jt...@pl...> - 2002-09-29 19:43:24
|
>I was thinking the same. Using a system like that being used with Wobjects and Macro's >you create a consistent interface for plugin modules. Anoyher benefit of this is that >something similar already has been implemented. I was thinking of putting all >auth-modules in a dir named something like WebGUI/Authen, just like WebGUI/Wobject for >Wobjects. Yup. Exactly. Except that there are no abbreviations in code in WebGUI. It's what makes the code so readable. So the directory will have to be "Authentication". Or at least I try to keep abbreviations out of the code. I suppose we could abbreviate thiis one to "Auth" since that seems to be the Perl standard on CPAN. http://search.cpan.org/search?mode=all&query=Auth >Because every authmethod uses different connection-parameters to connect, I think we >should let the modules bother with that. What I mean is that when the module needs to >connect it pulls the needed info from the db. That way you don't have to pass different >params to the methods of the module. I think that's the only way to create a universal >interface. Do you think it should be a userId and password, or a user object and password? >What I was thinking about is an "authen" method that takes userId and password as its >arguments. This method should then fetch all the needed connection data and the >serverlogin from the db, validate the password against the login and return true when >valid or, if not so, return the error code from the server. Yeah, I guess that means we'll have to create a new authentication table and move the auth info. The the users table will look like userId (PK) username authMethod dateCreated lastUpdated karma and the authentication table would look like userId (composite PK) authMethod (composite PK) fieldName (composite PK) fieldData Is that what you're thinking? >I'm not exactly sure what you mean by this. Are you talking about updates server-side >or just in the WebGUI db? Well, I was thinking that we need a method of updating authentication information. For instance, WebGUI needs to change the user's password. I think that WebGUI's auth method should use the same mechanism as any other auth method, so therefore we'll need some sort of a set method. Same thing goes to LDAP. If you connect to an LDAP server that allows you to write to it, then we'll need a set method. Then again, maybe it would be easier to let WebGUI be the only auth method that can write to it's data source. Probably more secure that way too. So in that case we might add the "identifier" field back to the users table and let WebGUI's auth system be completely separated from the other pluggable systems. What say you? >AFAIK this is not possible with SMB, but I must admit that I haven't looked in to this >yet. Could you be more specific about what kind of arguments this methid should take? Well for LDAP for instance, you bind to the LDAP source just like you do when you're authenticating. But instead you run a search method. In WebGUI's registration mechanism I run a search against a fieldname defined in the settings. It is usually "shortname". So you can search the LDAP repository for a user where "shortname"="username" whatever the user types in. And that would return the connect dn. You could do the same and use any other field. Perhaps a field like "email". So return the connect dn for any user with an email address = "jt...@pl..." >What also is required are some methods that generatethe form lines that are now >hardcoded in www_editUser and the likes for the connection-data (like LDAP URL >etcetera). These things should return some HTML containing the input fields for these >options. It's easy to cycle through al the installed auth-modules and generate a list >with all auth-types, and execute their "config" methods. Yup. Also we'll need to create a new dynamic settings page that will allow admins to configure each of the authenication plugins. >an "authen(userId, password)" method. >an "error(errorcode)" method that returns a readable message. >an "update(???)" method that updates the auth info >a "search(?)" method that searchen for a server login name based on some criteria >a (few) "config" methods that 'draw' the input forms for connection data etcetera >a (few) "saveConfig" methods that store the entered data in the db. don't forget about a registrationForm method that would display whatever form the user needs to input when registering. Man. Now that we've been talking about this. I really think this is a big undertaking. Are you up for the challenge? JT ~ Plain Black Create like a god, command like a king, work like a slave. |