Thanks 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. Regards, Josh Holtzman American Data Company [EMAIL PROTECTED] Voice: (310) 470-1257 Fax: (310) 362-8454 Sun Microsystems iForce Partner -----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 11:31 AM To: Struts Users Mailing List Subject: Re: Struts Application Security within the Controller Layer >As a novice, but rapidly learning, Struts developer, I believe the logical >place to put these checks is to subclass the RequestProcessor and override >the processPreprocess() method with this logic? I think your analysis is right on; it's not *wrong* to implement the security with a base abstract action, but when you do that, you lose your single inheritance (and incur some probably trivial extra overhead by performing more of the request processing cycle before stopping.) However, for a simple app or quick proof-of-concept, this is sometimes a good way. Also, extending RequestProcessor can be mildly problematic if you have a few different kinds of changes you want to make to the request-processing life-cycle (again because of the limitation to single inheritance). You may be interested in experimenting with the (beta-quality) struts-chain package and it's "ComposableRequestProcessor", which allows you to define an arbitrary chain of commands for handling a request (and provides a default chain which recreates the standard RequestProcessor behavior.) As soon as Struts 1.2.1 is released (Real Soon Now), we'll begin the process of converting the Struts core to use the chain request processor. I think that developers will find it very empowering to have fine control over the entire request processing life cycle, rather than only ever writing actions. Joe -- 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]
