[
https://issues.apache.org/jira/browse/WW-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart closed WW-1522.
-----------------------------
Resolution: Won't Do
The proposal — scanning configuration at load time to pre-create
{{ActionConfig}} entries for all potential alias (DMI) methods — is technically
feasible but no longer worth implementing, for three reasons:
# *The stated benefits are already achievable via wildcard mappings.* Alias
methods that can be browsed, overridden by static actions, and given their own
validators, type converters, and resources are exactly what wildcard action
mappings provide today:
{code:xml}
<action name="*/*" method="{2}" class="actions.{1}">
{code}
This delivers configurable per-method actions with no implicit runtime
scanning, and it's the approach already recommended in {{default.properties}}.
# *Auto-generating configs for "all potential alias methods" enlarges the
attack surface.* There is no reliable signal for which public methods are
legitimate action targets, so enumerating them at startup would expose
reachable endpoints that today require explicit opt-in. This runs counter to a
decade of hardening around Dynamic Method Invocation and its associated
advisories.
# *DMI is disabled by default and de-emphasized.*
{{struts.enable.DynamicMethodInvocation = false}} has been the default for
years. Building additional infrastructure around DMI is at odds with the
framework's direction, and any such feature would realistically ship
disabled-by-default with negligible adoption.
Recommend closing as *Won't Fix*, with wildcard mappings documented as the
supported way to obtain configurable per-method actions. Happy to reconsider if
there's a concrete use case that wildcard mappings can't cover.
> Automatic Alias ActionConfigs
> -----------------------------
>
> Key: WW-1522
> URL: https://issues.apache.org/jira/browse/WW-1522
> Project: Struts 2
> Issue Type: Improvement
> Reporter: Ted Husted
> Priority: Major
> Fix For: 7.3.0
>
>
> Create ActionConfigs for Action class methods that do not already have aliases
> The initial "dynamic method invocation" implementation does not create an
> ActionConfig, but scans for a "!" and invokes the method directly. The
> implementation doesn't allow these alias methods to be browsed, overrridden
> with static actions, nor can they have their own validators, type convertors
> or resources.
> Rather than scan for dynamic method references at run time, an alternate
> approach would be to scan the configuration when it is first loaded and
> create ActionConfigs for all potential alias methods.
> See also http://www.mail-archive.com/dev%40struts.apache.org/msg25916.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
