[
https://issues.apache.org/jira/browse/WW-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Ström updated WW-4083:
----------------------------
Description:
If the ParameterInterceptor config element 'acceptParamNames' does not match a
name, but the ParameterNameAware accepts it, the interceptor will fail to set
it on the valuestack.
In ParametersInterceptor, the acceptParamNames config element is used in two
places on each interception:
* to fill up acceptableParameters. This is based on both acceptParamNames
config, AND any ParameterNameAware's acceptableParameterName(Strings) method.
* to setAcceptProperties on the MemberAccessValueStack. This ONLY uses the
acceptParamNames config.
The problem occurs if acceptParamNames config rejects a param, but
acceptableParameterName(String) accepts it. The ParameterInterceptor will go
try to set the value on the stack (since it was accepted by the
ParameterNameAware), but the stack will reject it since setAcceptProperites is
based on acceptParamNames only.
Not sure what the proper fix here is, but at least it explains the problem I'm
having and what other people might have.
The reason it was not accepted by the config was that after the WW-3973 change,
any parameter accepted by EITHER the config or the ParameterNameAware is passed
on. I tried to guard against this by setting a very restrictive config for
acceptableParameters (i.e. a dummy value which did not let ANY parameter
througH), with the idea that the ParameterNameAware would allow it.
The quick fix for me would be to just accept the parameter name explicitly in
the config, and skip the ParameterNameAware part, but I still want to report it
as it is probably not what is expected.
was:
If the ParameterInterceptor config element 'acceptableParameters' does not
match a name, but the ParameterNameAware accepts it, the interceptor will fail
to set it on the valuestack.
In ParametersInterceptor, the acceptParamNames config element is used in two
places on each interception:
* to fill up acceptableParameters. This is based on both acceptParamNames
config, AND any ParameterNameAware's acceptableParameterName(Strings) method.
* to setAcceptProperties on the MemberAccessValueStack. This ONLY uses the
acceptParamNames config.
The problem occurs if acceptParamNames config rejects a param, but
acceptableParameterName(String) accepts it. The ParameterInterceptor will go
try to set the value on the stack (since it was accepted by the
ParameterNameAware), but the stack will reject it since setAcceptProperites is
based on acceptParamNames only.
Not sure what the proper fix here is, but at least it explains the problem I'm
having and what other people might have.
The reason it was not accepted by the config was that after the WW-3973 change,
any parameter accepted by EITHER the config or the ParameterNameAware is passed
on. I tried to guard against this by setting a very restrictive config for
acceptableParameters (i.e. a dummy value which did not let ANY parameter
througH), with the idea that the ParameterNameAware would allow it.
The quick fix for me would be to just accept the parameter name explicitly in
the config, and skip the ParameterNameAware part, but I still want to report it
as it is probably not what is expected.
Summary: ParametersInterceptor acceptParamNames and
ParameterNameAware's acceptableParameterName conflicts (was:
ParametersInterceptor acceptableParameters and ParameterNameAware's
acceptableParameterName conflicts)
> ParametersInterceptor acceptParamNames and ParameterNameAware's
> acceptableParameterName conflicts
> -------------------------------------------------------------------------------------------------
>
> Key: WW-4083
> URL: https://issues.apache.org/jira/browse/WW-4083
> Project: Struts 2
> Issue Type: Bug
> Reporter: Johan Ström
>
> If the ParameterInterceptor config element 'acceptParamNames' does not match
> a name, but the ParameterNameAware accepts it, the interceptor will fail to
> set it on the valuestack.
> In ParametersInterceptor, the acceptParamNames config element is used in two
> places on each interception:
> * to fill up acceptableParameters. This is based on both acceptParamNames
> config, AND any ParameterNameAware's acceptableParameterName(Strings) method.
> * to setAcceptProperties on the MemberAccessValueStack. This ONLY uses the
> acceptParamNames config.
> The problem occurs if acceptParamNames config rejects a param, but
> acceptableParameterName(String) accepts it. The ParameterInterceptor will go
> try to set the value on the stack (since it was accepted by the
> ParameterNameAware), but the stack will reject it since setAcceptProperites
> is based on acceptParamNames only.
> Not sure what the proper fix here is, but at least it explains the problem
> I'm having and what other people might have.
> The reason it was not accepted by the config was that after the WW-3973
> change, any parameter accepted by EITHER the config or the ParameterNameAware
> is passed on. I tried to guard against this by setting a very restrictive
> config for acceptableParameters (i.e. a dummy value which did not let ANY
> parameter througH), with the idea that the ParameterNameAware would allow it.
> The quick fix for me would be to just accept the parameter name explicitly in
> the config, and skip the ParameterNameAware part, but I still want to report
> it as it is probably not what is expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
