Christopher & Mark,
> The redirect approach was my first thought, cause that's what > I've done in > past applications, but I'm not a huge fan of it. For one > thing I prefer > POST to GET. Query string manipulation is a common security > vulnerability, > and while I always try to protect against it, hiding the > query string adds > a little (albeit very little) bit more security (I never try > hacking a > POST app when I can mess with someone elses GET app instead =). > I actually have to use POST instead of GET (company security policy). > In addition, I'm making use of the Apache::Session modules, > so I need to > pass the session id around between executions. With your > 'runmode/redirect/runmode/print' solution the first runmode > would need to > be responsible for ensuring that the session id was included > in the get > string. In my 'runmode/runmode/print' solution, the session > id is added > via TMPL_VAR to the template that gets wrapped around the > entire output, > at the instance script level. Basically, the way I do things, > alot of core > application functionality (session management, user > authentication, common > look, language preference, database connection, query_string > parsing, etc) > is encapsulated at a level seperate from the modules that > actually do the > work. The modules follow a very simple API, that wraps around > CGI::App's > (inherit from a base class, return don't print, etc). People > (interns) > writing the functionality just have to worry about the > 'content' of the > final application screen. > I don't use Apache::Session but I am using something similar called CGI::SecureState where I save the equivalent of a session id as a TMPL_VAR, so I agree with Chris here also. It is probably time to quit flogging a dead horse, but I echo Christopher's reasoning and suggestion (as follows) and would love to get a direct response as to why it is bad or otherwise undesirable. "I use CGI::App cause it's a very simple yet effective module that handles most of my requirements. I've looked at others, like HTML::Mason, and most were just too involved for my relatively simple undertaking. I'm going to use a sub-class to seperate the action() and output() from run(), but it would seem to me that this could be implemented in the core module and it would provide the same functionality the current implementation for those who need it, but would allow the flexibility for those who want it." Elizabeth PS - I have never participated in a mailing list for a perl module before, so please accept my apology if I am violating protocol in making a revision request in this manner. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
