I agree that execution semantics should be preserved (in an ideal
world at least).

But, if the intention is to enforce security of some parameter values
AND preserve action semantics, then the action should not change its
behavior/semantic if we call it from the context of a different
interceptor stack. That is, an action with its parameter secured (not
overwritten by user params) should remain secured whether it runs in
the paramsPrepareParamsStack, defaultStack, or even in the basicStack
for that matter.

This would require at least 2 things:
1) The developer of the Action class should declare somewhere that
some given parameters should be secured against user parameter
overwrite.
2) Even the most basic interceptor stack must enforce the rule.
(Otherwise, document it in a bold font)

To implement 1), you could use some xml configuration or annotation.
To implement 2), may be the natural place to put this control is
inside the params interceptor. Because you need this interceptor if
the security condition may fail (otherwise, there are no user
parameters to worry about.)

2008/8/4 Dale Newfield <[EMAIL PROTECTED]>:
> Gabriel Belingueres wrote:
>>
>> Unless you put also those two kind of static parameters in your
>> action, then I think staticParams should need to be executed only
>> once.
>
> In any place where you have staticParams and/or actionMappingParams, I would
> expect the semantics of the action (and potentially the preparation of data
> for the action) to depend upon those values.
>
> A classic example of code re-use would be a single action method that can
> "do it's thing" for many scenarios, and for which there are numerous defined
> actions.  I'll pick a message sending action for this example, where these
> would be valid URLs:  sendMessageToGroup.action?groupId=12,
> sendMessageToUser.action?userId=2354, sendMessageToAll.action, etc., with
> each separate action definition setting some parameters so the single action
> method knows what to do.  Some uses of this action method can be more
> sensitive than others, and have different security constraints on the url
> (sendMessageToAll could be restricted to role ADMIN, for example).  If you
> don't always ensure that static and action mapping parameters are not
> overwritten by user specified values,
> sendMessageToUser.action?userId=2354&sendToAll=true could be a security hole
> allowing anyone to spam the entire site.
>
> Since setup that will effect the action execution can happen inside prepare,
> it's important that both prepare and the action method both see the correct
> values.
>
> -Dale
>
> ---------------------------------------------------------------------
> 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]

Reply via email to