[
https://issues.apache.org/jira/browse/WW-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848889#comment-13848889
]
Christoph Lenggenhager commented on WW-4257:
--------------------------------------------
Generally, I'm all for WW-4154 and restoring the old behavior.
The problem is that you have also introduced this behavior in the
{{SecurityMemberAccess}} class where it wasn't present before.
-
https://github.com/apache/struts2/commit/f6a07e63e62e13e72cc4ee3a034398b4b30abe03#diff-133b11975bdb4f580966d9abea9ffbe9
introduced the possibility to check member names using the
{{ParameterNameAware}} interface
-
https://github.com/apache/struts2/commit/4e98aaaa1b08cc37374d06e77cf78000d98c5ff0#diff-133b11975bdb4f580966d9abea9ffbe9
changed this check from an ORing the static configuration to ANDing it with
the {{ParameterNameAware}} interface
I could well imagine that it is a good thing to have a similar mechanism to
check member names as it is given for the parameters, but it should not use the
same interface. The implementing action has no means to grasp the context and
therefore does not know whether it is validating the parameter 'foo' or the
member 'foo'.
> ParametersInterceptor uses same method on ParameterNameAware interface to
> validate parameters and properties
> ------------------------------------------------------------------------------------------------------------
>
> Key: WW-4257
> URL: https://issues.apache.org/jira/browse/WW-4257
> Project: Struts 2
> Issue Type: Bug
> Affects Versions: 2.3.16
> Reporter: Christoph Lenggenhager
> Fix For: 2.3.17
>
>
> With version 2.3.16, the {{ParametersInterceptor}} uses the same method to
> validate parameter names and property names.
> As we use the {{ParameterNameAware}} interface to implement parameter
> whitelisting on action level, this breaks our case.
> It might not be how it is intended, but validating a property independent of
> the actual bean breaks our current implementation.
> Possible fixes would be:
> - alter {{ParameterNameAware}} to have an additional separate method to
> validate properties
> - introduce a new {{PropertyNameAware}} interface
> - introduce a new {{ParameterAndPropertyNameAware}} interface
> One could also consider to ignore the {{ParameterNameAware}} interface when
> validating properties, as for a parameter {{foo.bar}}, the values
> {{foo.bar}}, {{foo}}, and {{bar}} are passed to the ParameterNameAware
> interface, which one could see as a bit redundant. Especially given the fact
> that a context in the case of property validation is not provided. Therefore,
> it is impossible for the implementation to distinguish between a parameter
> and a property.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
