problem extending the ComposableRequestProcessor process chain

[at...@verizon.net]

Hello Everyone,

I've been working on a web application here and I've come up with a situation where I feel that extending the AuthorizeAction command class would be a quality solution to a challenge I am facing. When I complete this I would be willing to contribute this back for others to use.  Here is some necessary background on what I am trying to do. Sorry for the length on this:

The application I am working on has complex requirements for role-based authorization checks. When the check fails and the user is not authorized, we do not want to just throw an exception or report an error.  We want to direct the user to a page with instructions on how they can become authorized. Many of the actions will have different requirements, and therefore different checks and different pages with different instructions.  

I came up with what I thought was an elegant and cheerfully easy way to do this, but it has not been so easy as I thought. In the struts-config.xml file I define the action, including its roles, and I include a forward for where the instructions are located for users who fail the authorization checks. Here is an example of one of these actions:

<action path="/orders/create"
       type="mypkg.CreateOrderAction"
       roles="createOrders">
       <forward name="unauthorized"
                path="/help/ordersHowTo.do"
                redirect="true"/>
</action>

I then wrote a class to replace the default AuthorizeAction class which is part of struts. It contains the complex logic which checks to see if the user has the createOrders role or not. If they do, it would return false to allow the chain to continue. If not, it would retrieve the ForwardConfig for "unauthorized", add it to the context, and then return  true to break what I was hoping was the "process-action" sub-chain, and then the "process-view" chain which executes next would retrieve the ForwardConfig from the context and then send the user there. Unfortunately this does not work the way I was anticipating :-(

What happens is that the chain stops completely at that point. This is where I get into trouble and I am hoping someone can point me in the right direction. Here is what the default servlet processing chain looks like for me:

<chain name="servlet-standard">

 <!-- Establish exception handling filter -->
 <command className="org.apache.struts.chain.commands.ExceptionCatcher"
catalogName="struts"
exceptionCommand="servlet-exception"/>

 <lookup catalogName="struts"
         name="process-action"
         optional="false"/>

 <lookup catalogName="struts"
         name="process-view"
         optional="false"/>

</chain>

Is there a way that I can terminate the "process-action" chain early but still have it execute the "process-view" chain after? I will greatly appreciate any help or suggestions that you can offer.

Best Regards,
Aaron Titus

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: problem extending the ComposableRequestProcessor process chain

[Joe Germuska <jo...@germuska.com>]

On 4/8/07, atitus74@verizon.net <at...@verizon.net> wrote:
>
> ...
> <lookup catalogName="struts"
>          name="process-action"
>          optional="false"/>
> ...
> Is there a way that I can terminate the "process-action" chain early but
> still have it execute the "process-view" chain after? I will greatly
> appreciate any help or suggestions that you can offer.


Yes.  LookupCommand has a property, "ignoreExecuteResult" that overrides its
default process to return whatever boolean is returned by the
looked-up-command.  You would turn it on like this:

<lookup catalogName="struts"
         name="process-action"
         ignoreExecuteResult="true"
         optional="false"/>

Intuitively, I expected the same behavior you expected, but that's not how
the commons-chain package was first implemented.  This should do it, unless
you sometimes want the lookup to return Command.PROCESSING_COMPLETE (that
is, true)  When using "ignoreExecuteResult," LookupCommand always returns
Command.CONTINUE_PROCESSING (false).

Joe

-- 
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com

"The truth is that we learned from João forever to be out of tune."
-- Caetano Veloso