This interceptor sets all parameters on the value stack.
This interceptor gets all parameters from
ActionContext#getParameters() and sets them on the value stack by
calling
ValueStack#setValue(String,Object), typically resulting in the values submitted in a form
request being applied to an action in the value stack. Note that the parameter map must contain a String key and
often containers a String[] for the value.
The interceptor takes one parameter named 'ordered'. When set to true action properties are guaranteed to be
set top-down which means that top action's properties are set first. Then it's subcomponents properties are set.
The reason for this order is to enable a 'factory' pattern. For example, let's assume that one has an action
that contains a property named 'modelClass' that allows to choose what is the underlying implementation of model.
By assuring that modelClass property is set before any model properties are set, it's possible to choose model
implementation during action.setModelClass() call. Similiarily it's possible to use action.setPrimaryKey()
property set call to actually load the model class from persistent storage. Without any assumption on parameter
order you have to use patterns like 'Preparable'.
Because parameter names are effectively OGNL statements, it is important that security be taken in to account.
This interceptor will not apply any values in the parameters map if the expression contains an assignment (=),
multiple expressions (,), or references any objects in the context (#). This is all done in the
#acceptableName(String) method. In addition to this method, if the action being invoked implements the
ParameterNameAware interface, the action will be consulted to determine if the parameter should be set.
In addition to these restrictions, a flag (
ReflectionContextState#DENY_METHOD_EXECUTION) is set such that
no methods are allowed to be invoked. That means that any expression such as
person.doSomething() or
person.getName() will be explicitely forbidden. This is needed to make sure that your application is not
exposed to attacks by malicious users.
While this interceptor is being invoked, a flag (
ReflectionContextState#CREATE_NULL_OBJECTS) is turned
on to ensure that any null reference is automatically created - if possible. See the type conversion documentation
and the
InstantiatingNullHandler javadocs for more information.
Finally, a third flag (
XWorkConverter#REPORT_CONVERSION_ERRORS) is set that indicates any errors when
converting the the values to their final data type (String[] -> int) an unrecoverable error occured. With this
flag set, the type conversion errors will be reported in the action context. See the type conversion documentation
and the
XWorkConverter javadocs for more information.
If you are looking for detailed logging information about your parameters, turn on DEBUG level logging for this
interceptor. A detailed log of all the parameter keys and values will be reported.
Note: Since XWork 2.0.2, this interceptor extends
MethodFilterInterceptor, therefore being
able to deal with excludeMethods / includeMethods parameters. See [Workflow Interceptor]
(class
DefaultWorkflowInterceptor) for documentation and examples on how to use this feature.
Interceptor parameters:
- ordered - set to true if you want the top-down property setter behaviour
- acceptParamNames - a comma delimited list of regular expressions to describe a whitelist of accepted parameter names.
Don't change the default unless you know what you are doing in terms of security implications
- excludeParams - a comma delimited list of regular expressions to describe a blacklist of not allowed parameter names
- paramNameMaxLength - the maximum length of parameter names; parameters with longer names will be ignored; the default is 100 characters
Extending the interceptor:
The best way to add behavior to this interceptor is to utilize the
ParameterNameAware interface in your
actions. However, if you wish to apply a global rule that isn't implemented in your action, then you could extend
this interceptor and override the
#acceptableName(String) method.
Using
ParameterNameAware could be dangerous as
ParameterNameAware#acceptableParameterName(String) takes precedence
over ParametersInterceptor which means if ParametersInterceptor excluded given parameter name you can accept it with
ParameterNameAware#acceptableParameterName(String).
The best idea is to define very tight restrictions with ParametersInterceptor and relax them per action with
ParameterNameAware#acceptableParameterName(String)
Example code:
<action name="someAction" class="com.examples.SomeAction">
<interceptor-ref name="params"/>
<result name="success">good_result.ftl</result>
</action>