We have similar issues. We are using NT for username and password auth. We also have corporate database tables with usernames, addresses, employee numbers, etc. We don't really have the requirement to have persistent information stored with the user, so we just created our own SecurityService and UserManager. The service just authenticates the username and password against the domain, and looks up information from our corporate tables, populating a TurbineUser object. We could write our own User object instead of using TurbineUser, but we really only are using it for storage. The only hacky thing is we use the confirmed field in the object to hold the users employee number. In the service we also populate the permissions and roles from the nt domain groups. Once we move to 2000, maybe we'll look at using ldap and hitting active directory for everything.
----------------------------------------------------------------- Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com ----------------------------------------------------------------- > -----Original Message----- > From: Pugh, Eric [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 04, 2002 8:43 AM > To: 'Turbine Users List' > Subject: RE: How to extend TURBINE_USER - a solution to the documented > pro blem > > > Scott, > > I am not sure how many changes you are proposing, but one > change that I > would love to see is that the interface User was a lot more > abstract. For > our company right now, we use microsoft technologies, and all > our users are > stored using NT Authentication. Until I can hook turbine up > to ask for a > username and password that is validated against the NT > domain, it doesn't > make sense for us to duplicate users passwords into the > Turbine tables. > Therefore, we decided as a stop gap, that since usernames > change rarely, but > passwords change frequently, that we would use an already > existing table > EMPLOYEE, and just add an OBJECTDATA column to it to store > extended Turbine > information. Unfortuantantly, the existing TurbineUser > interface has led to > a lot of problems for us. > > Our EMPLOYEE table schema: > EMPLOYEE_ID int > USERNAME varchar > ACTIVE bit > OBJECTDATA image > > Therefore we don't have things like getConfirmed values, Last > Access Date, > Last Name, Password, etc.. Now, a lot of that could have > been stored as > part of the ObjectData value, but we didn't need any of that. > > I ended up hacking up a lot of the Turbine's built in code > for handling > users to make it work with our system, but it is not very pretty. > Eventually, when we go back to having username AND password for > authentication, then we can go back to using the existing > Turbine system. > But in the meantime, what would have made life much easier > would be to have > a very basic interface for User and TurbineUser. That way we > wouldn't have > to dummy up a lot of values and methods. > > My code that I used is viewable as a zip at > http://briefcase.yahoo.com/dep4b > in the Java directory. > > Just my 2 cents... > > Eric > > -----Original Message----- > From: Scott Eade [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 04, 2002 6:36 AM > To: [EMAIL PROTECTED] > Subject: How to extend TURBINE_USER - a solution to the documented > problem > > > About a month ago I revisited the work I did earlier on > extending turbine_user. My goal was to overcome the > problem I had identified and documented about 3/4 of > the way down the extend-user-howto under the heading > "Additional Information (Added 12 Nov 2001)". To > summarise, after going through all of the effort to extend > turbine_user, the implementation is incomplete because > user.save() fails to save any related objects you may have > added using the generated user.addXXX() methods. > > By making some small changes to torque's Object.vm > template it is possible to have the code necessary to > save the related objects generated in the OM class > for the turbine_user alias. This solution is reasonably > small and it works well (I am using it in a production > site). > > The only trouble with this solution is that it seems a > bit like a hack because it mixes non-turbine security > objects with turbine security objects - you can include > the user.save() in a transaction, but the saving of the > actual turbine_user record will not be part of the > transaction because the turbine db security > implementation does not allow for this. > > Anyway, I have a solution that works. My question > is, should I submit a patch to Object.vm that could > be considered to be a hack or should I just outline the > hack in a patch to extend-user-howto so that interested > users can apply the patch themselves? > > > BTW: Anyone that has extended turbine_user will love > this change. With it you can use data.getUser() just > like any other OM class (after casting it to your alias > class). > > Any thoughts? > > Scott > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
