Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.11.1, 2.0.11.2, 2.0.12, 2.0.13, 2.0.14, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.8, 2.1.8.1, 2.2.1, 2.2.1.1
    • Fix Version/s: 2.3.1
    • Component/s: Core Actions
    • Labels:
      None
    • Flags:
      Important

      Description

      In all current Struts 2 version you can use Dynamic Method Invocation to call particular public Action's method use syntax:

      /actionname!methodname

      It can be disabled by defining constant struts.enable.DynamicMethodInvocation = false

      The idea is to totally remove such functionality from the project.

        Issue Links

          Activity

          Hide
          John Lindal added a comment -

          Removing the functionality entirely would severely break backward compatibility.

          Show
          John Lindal added a comment - Removing the functionality entirely would severely break backward compatibility.
          Hide
          John Lindal added a comment -

          OK, I will check in the changes under WW-3264.

          Show
          John Lindal added a comment - OK, I will check in the changes under WW-3264 .
          Hide
          Lukasz Lenart added a comment -

          John it would be great!

          Show
          Lukasz Lenart added a comment - John it would be great!
          Hide
          Maurizio Cucchiara added a comment -

          See also http://www.mail-archive.com/dev@struts.apache.org/msg30304.html and http://www.mail-archive.com/dev@struts.apache.org/msg30333.html.

          It seems there is almost everything for make it works (see ActionConfig.isAllowedMethod for further details), except a way to configure it.

          Show
          Maurizio Cucchiara added a comment - See also http://www.mail-archive.com/dev@struts.apache.org/msg30304.html and http://www.mail-archive.com/dev@struts.apache.org/msg30333.html . It seems there is almost everything for make it works (see ActionConfig.isAllowedMethod for further details), except a way to configure it.
          Hide
          Dave Newton added a comment -

          Could this be handled w/o DTD change by using a MethodFilterInterceptor against ActionProxy's method name?

          Show
          Dave Newton added a comment - Could this be handled w/o DTD change by using a MethodFilterInterceptor against ActionProxy's method name?
          Hide
          John Lindal added a comment -

          DMI can be quite useful. That's why it was added

          The right solution is to provide access control. In my hacked version of 2.2.1, I use a whitelist configuration, so only functions explicitly added to the whitelist can be invoked. (execute is the exception, since it is the default.)

          Let me know if you want me to contribute patches for this. It requires a change to the DTD so the whitelist can be configured for each action.

          Show
          John Lindal added a comment - DMI can be quite useful. That's why it was added The right solution is to provide access control. In my hacked version of 2.2.1, I use a whitelist configuration, so only functions explicitly added to the whitelist can be invoked. (execute is the exception, since it is the default.) Let me know if you want me to contribute patches for this. It requires a change to the DTD so the whitelist can be configured for each action.
          Hide
          Maurizio Cucchiara added a comment -

          Many users would be forced to keep 2.2 version due of the removal.
          Why don't we think a way to expose/unexpose method invocation?
          Let's take for example:
          I choose to disable DMI then can I selectively choose which method should be exposed through annotations?

          Show
          Maurizio Cucchiara added a comment - Many users would be forced to keep 2.2 version due of the removal. Why don't we think a way to expose/unexpose method invocation? Let's take for example: I choose to disable DMI then can I selectively choose which method should be exposed through annotations?
          Hide
          Paweł Wielgus added a comment -

          Hi All,
          if i understand it right after removing it completely i will no longer be able to call my edit page like this:
          /mynamespace/mysaveaction!input
          if it's the case please reconsider just making it not default or suggest other solution for my case - maybe i do it simply wrong - who
          knows.

          The background is i don't use xml configuration, so adding EditAction would result in adding extra class which is not necessary.

          Show
          Paweł Wielgus added a comment - Hi All, if i understand it right after removing it completely i will no longer be able to call my edit page like this: /mynamespace/mysaveaction!input if it's the case please reconsider just making it not default or suggest other solution for my case - maybe i do it simply wrong - who knows. The background is i don't use xml configuration, so adding EditAction would result in adding extra class which is not necessary.
          Hide
          Martin Gainty added a comment -

          unless there is a egregious effect upon any part of the codebase (as demonstrated by a testcase) then
          let it be

          Show
          Martin Gainty added a comment - unless there is a egregious effect upon any part of the codebase (as demonstrated by a testcase) then let it be
          Hide
          Dave Newton added a comment -

          I don't see any compelling reason to remove it, and it's pretty easy to deal with.

          Show
          Dave Newton added a comment - I don't see any compelling reason to remove it, and it's pretty easy to deal with.
          Hide
          Philip Luppens added a comment -

          Why would you totally remove this functionality? Just set the default value of the constant to false. Unless there is some other impact ...

          Show
          Philip Luppens added a comment - Why would you totally remove this functionality? Just set the default value of the constant to false. Unless there is some other impact ...

            People

            • Assignee:
              Lukasz Lenart
              Reporter:
              Lukasz Lenart
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development