3) Your app will work as a Struts module (sub-app), should you choose to do that at a later date. For an app to work as a module, all requests *must* go through the controller.
-- Martin Cooper > -----Original Message----- > From: Troy Hart [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 30, 2002 3:58 PM > To: Struts Users Mailing List > Subject: RE: Security and Struts > > > I don't think it is that much work to put an action in front of every > jsp page that represents "page" in your application. I > actually think it > is a very good abstraction. A couple of the advantages I can think of > right now include: > > 1) It gives your web-app a stable interface and simultaneously allows > you to freely swap the actual response generating resource, behind the > scenes. You provide a action mapping where you tie a stable name to an > action class, or even some other arbitrary resource...whatever suits > you. Along with this approach, most people will hide the jsp > in WEB-INF. > I've heard reports of some having troubles with the hiding > part, but it > has worked well for me. > > 2) You can sleep well at night knowing that all requests go > through your > special request processing logic...you won't have to worry about the > "secure" page that you forgot to include the special taglib on. This > need can arguably be mitigated by using cma/filters. > > Troy > > > On Tue, 2002-07-30 at 16:03, David Graham wrote: > > I've done it by using a custom tag on all the secured pages > that checks the > > login but this isn't ideal. I could forget to put the tag > in and I have to > > do it for every page. > > > > If you let struts do it then you can't let people go to > .jsp pages directly > > and I find this irritating at best. > > > > Should you only use struts for the webforms and not for > public display > > pages? I've always been a bit confused by this. It seems > that struts was > > designed for the forms stuff but not necessarily to sit in > front of your > > whole app. > > > > Thanks, > > Dave > > > > >I tend to think the action is the wrong place for this > sort of thing. I > > >could be wrong but that's just how it occurs to me. It > seems that this > > >should either be handled in front of your web application (using > > >cma/filters) or by the front controller components in the struts > > >framework (NOTE: requests that do not map to the > controller servlet, > > >like requests directly to a jsp page, will not invoke your request > > >processing logic). > > > > > >Struts also helps you along here. It provides a way for you to > > >*declare*, along with each action mapping (in struts-config.xml), a > > >specific set of roles that have access to the given > action. Then, the > > >RequestProcessor defines the method processRoles() that > you are free to > > >override, but by default it will invoke: > > > > > >request.isUserInRole(someRole) > > > > > >for each role declared in the action mapping. If the user > is found to be > > >included in any of the roles then processRoles() returns > true, otherwise > > >it returns false. True is also returned in the case where > no roles are > > >declared on the action mapping. Check out the struts > source for more > > >detail... > > > > > >Unless you use the cma/filters approach (and I haven't, so > I don't know > > >what the issues are there), there will still be some > details for you to > > >work out with respect to getting an authenticated user > into the session. > > >This could be handled in a number of different ways. One > that occurs to > > >me, off the top of my head, would be to wire a login page > into the page > > >that is forwarded when processRoles() returns false... > > > > > >There may be some mis-truths in what I have said here, I > am currently > > >working through some of this stuff, but in general I think > the idea is > > >sound. Certainly having declarative security is something that you > > >should strive for... > > > > > >If anyone has feedback on what I've said here, I would > love to hear it! > > > > > >Thanks & Good Luck, > > > > > >Troy > > > > > > > > >On Tue, 2002-07-30 at 12:59, Nelson, Tracy (ETW) wrote: > > > > I'd have each form check authorization. That way, if > someone bookmarks > > >a > > > > page (or guesses its URL) they won't bypass your > security scheme. You > > >could > > > > have a global exception set up in your configuration > file that forwards > > >to > > > > an "Access denied" page whenever one of your forms threw a > > >UserNotAuthorized > > > > exception. (NOTE: I am just learning Struts and > haven't even written my > > > > first application using it yet. I may not know what I > am talking > > >about.) > > > > > > > > Cheers! > > > > -- Tracy > > > > > > > > -----Original Message----- > > > > From: Ryan Cuprak [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, July 30, 2002 11:53 > > > > To: [EMAIL PROTECTED] > > > > Subject: Security and Struts > > > > > > > > > > > > > > > > Hello, > > > > I was hoping someone would have some advice on > securing a website using > > > > struts. I am developing a webapp that has to be secure > (password > > >protected) > > > > and which restricts access to different parts of the > site depending on > > >the > > > > roles a user possesses. The roles each user has are > stored as XML in a > > > > database and may be configured by an administrator. > Does struts have any > > > > built-in security capabilities that I could take advantage of? > > > > > > > > > > > > Any help/pointers would be much appreciated! > > > > > > > > My first guess would be to put all jsp pages in > WEB-INF (use only > > > > ForwardAction to get to each page) and subclass > ActionServlet with the > > >logic > > > > for check authentication etc. However, will this cause > any problems when > > >it > > > > comes to a user book marking a page? > > > > > > > > Thanks, > > > > -Ryan Cuprak > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > >-- > > >To unsubscribe, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > >For additional commands, e-mail: > > ><mailto:[EMAIL PROTECTED]> > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
