Hi,
I created the following Filter and it seems to work.

Note 
1) I used a custom security model, i.e. a login page inside my
application. And this solution implies the extension of
TilesRequestProcessor if you have a menu roles-based.

2) The object "userID" contains information regarding the user and it is
created in the login action.

3) chain.doFilter( request, response ) must be called in order to call
your Struts application.
BR
/Amleto


import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

public class SecurityFilter implements Filter {

    private static String URL_LOGIN = ""/ApplicationContext/login.do"";
    public void destroy() {
    }

    public void doFilter( ServletRequest request, ServletResponse
response, FilterChain chain )
            throws ServletException, IOException {
        HttpServletRequest httpServletRequest = (HttpServletRequest )
request;
        HttpSession session = httpServletRequest.getSession( false );

        if ((httpServletRequest.getRequestURI().indexOf( URL_LOGIN
)==-1) &&
            ( (session==null) || (session.getAttribute( "userID"
)==null))) {
            httpServletRequest.getRequestDispatcher( "/index.jsp"
).forward( request, response);
            return;
        }

        chain.doFilter( request, response );
    }

    public void init( FilterConfig config ) throws ServletException {

    }

}

> -----Messaggio originale-----
> Da: Dakota Jack [mailto:[EMAIL PROTECTED] 
> Inviato: giovedì 20 gennaio 2005 15.54
> A: Struts Users Mailing List; [EMAIL PROTECTED]
> Oggetto: Re: Session Strategy
> 
> 
> I am also too lazy to make a filter!  LOL  ;-)  Anyone have 
> one of these in their toolbox they would like to share?
> 
> Jack
> 
> 
> On Thu, 20 Jan 2005 12:49:41 +0800, Andrew Hill 
> <[EMAIL PROTECTED]> 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]
> > 
> > 
> 
> 
> -- 
> ------------------------------
> 
> "You can lead a horse to water but you cannot make it float 
> on its back."
> 
> ~Dakota Jack~
> 
> "You can't wake a person who is pretending to be asleep."
> 
> ~Native Proverb~
> 
> "Each man is good in His sight. It is not necessary for 
> eagles to be crows."
> 
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> 
> -----------------------------------------------
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/01/2005
>  
> 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/01/2005
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to