struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Hill <andrew.david.h...@gridnode.com>
Subject Re: Session Strategy
Date Thu, 20 Jan 2005 04:49:41 GMT
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message