Joe, Your suggestion sounds interesting, but I'm not sure if I fully understand it.
Correct me if I'm wrong. You suggest extending the ActionMapping class and adding the fields to this class that I will need for checking the user group that may access this path/resource. Let's say this is a simple application, and there is an integer or string that is stored, identifying the access level to this resource. So, when this class is built, would it represent an action within my struts config file, and with the changes permit me to somehow specify the permission level that has access to the action? I'm a little confused about the "SecureActionMapping" interface you mentioned. However, if what you are suggesting is that the extended ActionMapping would now contain the role that has access to this action, I could then extend the RequestProcessor to inspect the permitted user group that is stored in the new ActionMapping class, and compare it to the permission level stored in the User's session. If these don't agree with one another, the user does not have access to the path/resource, and will be directed to an error page. Is this what you had in mind? If so, I'm still a little confused about how to extend the ActionMapping so it would contain the correct permission level info for access to the resource. How/where would this information be configured. I think you might be suggesting additional XML elements or attributes may be added to the Action element in the StrutsConfig file, but I'm not sure. Please let me know your thoughts. Everyone else is also free to comment. Regards, Josh -----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, April 16, 2004 9:07 AM To: Struts Users Mailing List Subject: RE: Struts Application Security within the Controller Layer The way to configure this flexibly for each action would be to define an extension of ActionMapping that was a bean with whatever config properties you need (for instance, a role or list of roles permitted to access the action.) Of course, since each path gets only one ActionMapping, you may need to use a "SecureActionMapping" interface that you could implement with various mapping classes. (It seems to take Struts users a while to get into the idea of using ActionMapping to provide extended configuration information to an Action class, but it can be a very nice way to avoid re-coding the same logic over and over.) Once you have this, you could either find another spot in the request processor to enforce this logic (very easy with a chainable processor, of course), or use a "SecureAction" base class from which you extend for any paths which must be controlled, which would do authorization before passing control to the subclass. Joe >I'll look into the "ComposableRequestProcessor" for future projects. This >seems like it could be a very powerful feature, if used correctly. > >Since we are on the subject of Control and security, let me throw in another >question. > >My application has three different user permission levels. >1) User >3) Super User >2) Admin > >Each account in the DATABASE is classified with one of these permission >levels. > >I want to also inspect each request before an Action is dispatched to >confirm that the User should be granted access to execute the Action. > >At first thought, it seems that I cannot use the processRoles() feature of >the RequestProcessor, because my permission levels are not stored into the >config file, but rather in the database. Or should I say, I cannot take >this approach without overriding this method (which may be a solid >approach.. but I haven't thought it out much. I imagine this would require a >way for me to map each action with the correct access groups). > >I could put this logic into each Action class, but, for obvious reasons, >this will be a maintenance nightmare. > >Can anyone offer any suggestions on these or other approaches? > >Your assistance is greatly appreciated as it always is. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
