Chris: I implemented your suggestion and came across another question. What if the User has more than one role, or a particular action subclass needs to accommodate more than one role? For example say the application has four roles: admin, paidUser, nonPaidUser, guest. So how do we approach the issue of a User has the roles of paidUser and guest, or the action subclass (viewAccountAction) needs to accommodate the paidUser and nonPaidUser roles? This is an problem because currently the action subclass can only implement one perform method.
Thanks Chong -----Original Message----- From: Bartley, Chris P [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 8:21 AM To: 'Struts Users Mailing List' Subject: RE: Struts logic question I've solved the role authorization problem with a hierarchy like this: Action | \---ActionSupport | \---AuthenticationVerifyingAction | \---RoleAwareAction | \---[your classes here] Here's a brief description of what each class does: Action: standard Struts action class ActionSupport: provides some common constants and methods for all my action classes AuthenticationVerifyingAction: this class's perform() method verifies that a user is logged in. If so, it simply calls performAfterAuthenticationVerification() which is typically overridden by the subclass. If not, it calls performUponFailedAuthenticationVerification() which forwards the user to the login page unless the subclass has overridden it to provide special functionality. RoleAwareAction: this class's performAfterAuthenticationVerification() method determines the role (user or administrator) of the logged-in user, and calls either performForAdministrators() or performForUsers() accordingly. These two methods simply forward to an Access Denied page, so subclasses will simply override them accordingly. This allows actions to easily perform different tasks for the different role types without having to rewrite the branching logic every time. A side benefit is that for actions that may only be accessed by a particular role, the subclass need only override the appropriate method--users that do not belong to that role will be presented with the Access Denied page. Actions that perform the exact same logic regardless of role should instead just subclass AuthenticationVerifyingAction. Hope that helps. chris > -----Original Message----- > From: Chong Oh [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 09, 2002 10:05 AM > To: 'Struts Users Mailing List' > Subject: RE: Struts logic question > > > Joseph: > > I have a follow up question on this subject. How would you approach > authorization? For example, if different roles have different access > to different JSPs in the application, do we validate user access > on each page > (using custom tags) or should we add that as another function into the > Action Class subclass (using the Action Class approach)? > Your help is much > appreciated. > > Chong > > > > -----Original Message----- > From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 08, 2002 1:52 PM > To: Struts Users Mailing List > Subject: RE: Struts logic question > > > Since every JSP that is hit by a user request should go > through an Action > class, it makes more sense to do your login check in an > Action class (or a > Servlet Filter if you're using the 2.3 API). If you go the > Action class > route, the approach we use is as follows: > > 1. When a user logs in, put a "token" (a bean containing > login information, > perhaps) into the session. > > 2. Create a subclass of the Action class which all your > Action classes will > subclass, called AuthenticatedAction or whatever you like. You should > probably make this an abstract class with an abstract > "performAction" method > (name your choice) for the sublclasses to implement. This > method will have > the same signature as the "perform" method except for its name. > > 3. In this AuthenticatedAction class, the perform method > checks for the > token's existence in the session. If it's not there, the > user isn't logged > in, so forward them to the login page. If the token is there, call > "performAction()" to execute the subclass's logic and > determine the forward > to return. > > There are myriad ways of accomplishing login authentication upon each > request; another way is through the use of a ServletFilter attached to > the Struts ActionServlet (and any other Servlets you may have and wish > to enforce authentication on). > > You can also do the login check through the use of custom > tags if you allow > access to some JSPs directly, NOT through an Action class. > IMO it is best > to be consistent though and stick with one or the other > according to your > needs. > > Also, if you authenticate at the JSP level (through a custom tag or > scriplet) and not at the Action level, then your actions > could be hit with a > request in which they do a whole bunch of processing, then > forward to a JSP > which immediately blocks the user and directs them to a login > page. Not > very efficient, if you ask me. > > peace, > Joe Barefoot > > > -----Original Message----- > > From: Russell Beattie [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 08, 2002 1:33 PM > > To: Struts Users Mailing List > > Subject: Re: Struts logic question > > > > > > > > > > Sorry to post again, but could someone help me on this? > > > > Thanks, > > > > -Russ > > > > > > > > Russell Beattie wrote: > > > > > > > > Hey everyone, > > > > > > I can't get into the mail archives right now, so I hope > this isn't a > > > completely horrible newbie question. > > > > > > I'm using Struts for the first time and have a general idea how > > > everything is being done. The one question I have > concerns "standard > > > logic" for every page. For example, I want to check that > the users > > > are logged in. In other words, you need to log in to the website > > > before viewing any page so I want all .jsp pages to check > if you're > > > logged in or not, and if not, pull up "login.jsp." > > > > > > This seems pretty standard to me, but I can't figure out > how to do > > > this sort of thing using the Struts framework. I'm using > templates, > > > should I just throw a bunch of basic logic into the > > > defaultTemplate.jsp page? Or should I use > <servlet-mapping> to map > > > .jsp pages to a standard logic applet, which will then pass it on > > > through to be processed? Or is there something REALLY > basic that I'm > > > missing? > > > > > > Thanks for your help in advance, > > > > > > -Russ > > > > > > > > > > > > > > > > > > > > > -- > > > 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]> > > -- > 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]>
