Sorry for not getting back into the thread, been a busy day. :) Chong: You're welcome for the action authentication tip, I borrowed it from someone else.
As far as the role-based authorization: I like Chris Bartley's class hierarchy-based authorization because it's aesthetically pleasing, however it does have limitations in that new roles with authorization cannot be added without adding methods, as I see it. We have many roles in our system, and we use an "access key" method of authorization, as follows: Every action in our system has a resource key associated with it in the resources file (e.g. action.user.corporate.add). The key's value will likely be the text displayed for that action (link, toolbar or menu item, button, etc.), e.g. "Modify Account" or "Add User". You can associate user roles with the key either in an XML file or through database tables...in the case of an XML file, you should also have an interface class which contains the legal roles as static constants. Use a "Authorization Engine" which loads the key-roles associations into memory for rapid access by your Actions. You can associate this "action key" with an ActionMapping by using the optional "parameter" element in the mapping, setting it's value to the key name (I think the new Struts version also has optional "setProperty" elements you could use) . Then, in your "AuthenticatedAction" class's perform method, firs make sure the user is logged in and has a defined role in the session, then retrieve the action key from the mapping (the "parameter" value) for this URL, and use the Authorization Engine to see what roles are allowed for this key. Based on this you can forward or deny the request. Note that by using the keys this way, you can also determine whether to display a particular action key's link on the page based on the user role. Before forwarding to a page, you would check the roles for every action key on the page and determine whether to display a particular link. Note also that this would only have to be done once (and then cached in the session) if you have a "toolbar" or "menu" style approach to actions. The only side-effect of this model (that I know of) is that you have to preserve the resource key name in three places: the resources file, the struts-config, and your XML roles file (or your database). > -----Original Message----- > From: Chong Oh [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 09, 2002 8: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]>
