On Feb 3, 2005, at 5:52 PM, Jaclyn Whitehorn wrote:
I'm about to have to re-do some applications, so I was hoping to get a jump on it by seeing if anyone has some advice.Current situation:- Multiple applications that use same (LDAP) login info to accomplish basic tasks. (Our "tools") - My "SuperApp" module is a subclass of CGI::Application. It handles authentication and sessions, overrides the load template method (so that I can use separate headers and footers), and makes some basic assumption about file locations. - Other applications are subclasses of the SuperApp. Some are more complicated (with helper modules managing DB connections or .procmailrc files, for example) than others. - Each application has its own .pl file that instantiates and runs the particular application object.What I have to do: - Recreate each one to work in a single sign on (portal) environment.We've added a portal (commercial product based on uPortal) and want these tools to be available from within there. The portal tech team is going to work with me so that they can send a trusted key that will tell me that the person is authenticated and their user name (which is all I need). So anyone got some examples on how I should proceed? After a certain point, almost all of the applications will be only available via the portal, so I'm OK with re-doing a "PortalSuperApp". (Or more likely, take the authentication out of the SuperApp, then have a WebSuperApp and a PortalSuperApp both subclassed from there. No wonder I'm procrastinating!)
In the "production" environment, I think many servers do have mod_perl enabled. (Not being in a production environment, I am speaking entirely off the cuff!) That said, even if running scripts under plain CGI for backwards compatibility reasons, memory reasons, etc., one can almost certainly benefit from using the authentication/authorization handlers in mod_perl. For example, you can put the authentication/authorization handler in front of any path you wish. If you have a path http://www.myserver.com/portal, everything under that path will be protected by the same authen/authz handler. No need to put that into the cgi scripts at all. This has obvious benefits for application development of the kind described above, as it doesn't require any of the individual scripts to deal with authen/authz at all. My development stuff is like what is described above. I had a closed (intranet) server that I suddenly had to put outside the firewall for just one project. Rather than go back through and modify every legacy script or cgi::app, I just put an authen/authz handler in the httpd.conf for the path and, voila, I had a relatively secure setup without having to recode within my apps. Security theory aside, for my system, separating security from apps was the shortest path to get the job accomplished. As for authen/authz handlers, I wrote my own, but there are MANY examples available at CPAN. Here are a couple of book chapters that I found quite useful:
http://www.modperlcookbook.org/chapters/ch13.pdf http://modperl.com:9000/book/chapters/ch6.html
I've also considered integrating them a bit more while I'm at it, but I do still want each one in its own module. I'm pretty comfortable with my "helper" modules, but I've never had a setup where runmodes were in different modules. So if anyone has experience there either, I'd love to have some more code to look at.And using something like cgi::application::dispatch would simplify things further in the transition.
http://cpan.uwinnipeg.ca/htdocs/CGI-Application-Dispatch/CGI/ Application/Dispatch.html
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.