Look at the http://www.securityfilter.org project on sourceforge. It provides a portable implementation that is similar to container security but can be regarded as an improvment in some cases. request.isUserInRole will work and also struts role checking.
-----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: 07 July, 2003 18:21 To: Struts Users Mailing List Subject: Re: Webapp Security? On Sun, 7 Jul 2003, Rick Reumann wrote: > Date: 07 Jul 2003 00:47:20 -0400 > From: Rick Reumann <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: Re: Webapp Security? > > On Thu, 2003-07-03 at 16:42, Craig R. McClanahan wrote: > > > > > > Why are you trying to mess with the container's implementation of > > authentication at all? Why not just write a Filter that does an > > RD.forward() to some safe place if it sees that the session does not > > contain the right stuff (because it was timed out and recreated)? > > Remember, a filter is *not* required to call chain.doFilter() to pass the > > request on -- it can forward wherever it wants and then return, and this > > is portable to any Servlet 2.3 container. > > > > Filters are your friend :-). > > > Well, here's the deal... Basically there are are too many things that > rely on certain objects being in Session scope for this application so I > don't want to have to test every type of action url. So what I did was > write a Servlet Filter that also is called from the urr pattern /* > > the relevant filter method looks like : > > if ( httpRequest.getUserPrincipal() != null && > session.getAttribute("userBean") == null ) { > RequestDispatcher rd = request.getRequestDispatcher(mainPage); > rd.forward(request, response ); > } > else { > chain.doFilter(request, response); > } > > > The above seems to work fine- forcing the forward to the mainPage (which > in my case is an index page that then forwards to an Action that sets up > appropriate Session information). > > Throughout the course of the application there are other session objects > (mainly some Lists for reporting that are put in Session scope) so > rather than test for everything and have to figure out what page/action > to bring the user to in oder to make things are set up correctly, I just > want them all back some initial page. > > The part I don't like is every request now has to hit both the security > filter and this other filter. Would it maybe be better to maybe just do > this type of check in my base action execute method? (check for the > userBean being null there and if null forward to the appropriate > setUpAction? > I wouldn't be concerned -- combining things through composition (versus putting everything in one big class) makes the individual pieces much easier to understand and maintain. Also, note that the Filter approach works even if your user tries to request a JSP page directly, while embedding the logic in your Action would not catch this. > Thanks, > > -- > Rick Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __________________________________________________________________________________________________________________________________ For information about the Standard Bank group visit our web site <www.standardbank.co.za> __________________________________________________________________________________________________________________________________ Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. ___________________________________________________________________________________________________________________________________
