[
https://issues.apache.org/jira/browse/WW-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485174#comment-14485174
]
Jasper Rosenberg commented on WW-4486:
--------------------------------------
Wow, that is problematic to say the least. Is there a discussion somewhere I
can look at which talks about the specific spots where double evaluation can
happen? I'm guessing the ConversionErrorInterceptor is one of them. I can't
seem to reproduce setting a value and having ognl evaluate it on the way in
though. By any chance do you have a sample expression that i should be able to
pass in as a value to a struts textfield tag and see ognl try to evaluate it?
Thanks!
> Default parameter exclusions blocking legitimate values
> -------------------------------------------------------
>
> Key: WW-4486
> URL: https://issues.apache.org/jira/browse/WW-4486
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.3.20
> Reporter: Jasper Rosenberg
> Priority: Critical
> Fix For: 2.5
>
>
> In ParametersInterceptor.setParameters(), when building
> acceptableParameters(), it applies the check isAcceptableValue not just just
> to the parameter name, but also to the parameter value. This is a huge
> problem because the default excludedPatterns include phrases that will come
> up in normal user form submissions.
> For example, the way I discovered this is that one pattern is
> "(.*\.|^|.*|\[('|"))\bclass(\.|('|")]|\[).*"
> We are a car site, so when a user tried to post a message about a Mercedes M
> class: "That's M class. You asked for G class, different beast!"
> The "class." at the end of the first sentence was rejected and so their post
> failed.
> What is the reason for applying the exclusion patterns wholesale to the
> parameter value? Is it even necessary at all, or is there some kind of
> escape character that normally tells ognl to evaluate an expression in the
> value, in which case we could check for exclusion pattern matches just within
> those?
> As it is though, the current solution is going to cause some occasional very
> peculiar behavior for developers. Not sure if this should actually be a
> blocker bug since the only reasonable workaround seems to be to hack the
> ParametersInterceptor locally (since one shouldn't remove the exclusion
> patterns in general).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
