struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Session Strategy
Date Thu, 20 Jan 2005 05:05:22 GMT
That's an interesting view of JSPs.  I've always thought of WEB-INF as 
configuration and support files only.  In that mindset, a JSP wouldn't 
fit because it is a piece of the application itself, not configuration 
and not a support file, like JARs would be for instance.

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

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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message