In any case, I'm not trying to argue the point or anything, it's certainly a valid approach. Just an interesting perspective to me is all.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Andrew Hill wrote:
Id support the filter suggestion, though for myself I generally do the check in the RequestProcessor, as Ive usually overrideen it to perform other evil anyhow, and Im lazy to make a filter.
If you dont keep your JSP under WEB-INF (IMHO thats where they belong because they are 'code & config' , just like your classes,jars, and struts-config.xml and tlds) then you should declare some sort of security constraint so they can only be reached by a server side forward from their respective preperation action.
Frank W. Zammetti wrote:
If the user clicks a button, you are either going to (a) go directly to a JSP, which is generally not a good idea in a Struts-based application anyway (or any servlet-based application for that matter) or (b) go to an Action, as you probably should be doing. In either case, choice 1 is what I would do personally. Putting things under WEB-INF as David suggests works great, but it just feels kind of wrong to me.
You'll also want to call some common code from all your Actions that does the same basic check and forwards immediately to your "logon again" page. I do this by means of an ActionHelpers class that has two static methods, start() and finish() that are called, as I'm sure you could guess, at the start and end of all my Actions. They do some common tasks, including this check.
If you want a real solution though, externalize your security using something like Netegrity Siteminder. It will deal with this situation for you, in a theoretically more secure fashion than you could probably do on your own.
Yet another idea is a filter that will check if a session is alive and redirect as appropriate. This I believe can work no matter what your request is to (Action or JSP directly), or any other resource, assuming the app server serves everything.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
