This capability is indeed similar to strict method invocation but for
request parameters. I'm not against an XML based alternative for those
who prefer it.
It might lose some additional benefit that comes with co-location of
configuration with code though.
With annotations, anyone reading the Action class code is immediately
aware which methods are invocable via parameter injection without
needing to cross reference XML. It prevents situations where a
developer may change what looks like a normal getter/setter method
code without realising it is invocable via parameter injection.
There is also often a misunderstanding about the role of getters and
setters in the injection process. Now, parameter injection will only
succeed if you have annotated the exact method required for injection
of that specific parameter. Forcing developers to acknowledge how a
request parameter corresponds to an invocable method promotes more
conscious and secure coding.
For example, the getter methods you've included in your code snippet
above have no involvement in injecting a String type parameter, and
annotating those methods would thus have no effect. If you were to
annotate the corresponding setters instead, it would enable their
injection.
However, for parameters involving a POJO/DTO (or "bean"), you would
annotate the getter with an appropriate depth setting - as that is the
code path OGNL takes to perform parameter injection in that case.
On Sun, Jun 23, 2024 at 7:25 PM Greg Huber <gregh3...@gmail.com> wrote:
>
> Going through my parameters, as I share alot of screens in various parts
> with different requirements, a struts.xml version on the action, similar to
>
> <allowed-methods>save,publish,expire</allowed-methods>
>
> would work well here ie
>
> <allowed-parameters>path,filter</allowed-parameters>
>
> public String getPath() {
> return path;
> }
>
> public String getFilter() {
> return filter;
> }
>
> Just an idea.
>
> On 18/06/2024 08:57, Kusal Kithul-Godage wrote:
> > Yeah good call I'll look into it
> >
> > On Tue, Jun 18, 2024 at 5:54 PM Greg Huber<gregh3...@gmail.com> wrote:
> >> OK thanks.
> >>
> >> Can the logging be the same others - Developer Notification rather than
> >> changing the debug level?
> >>
> >> ie for a bad date I get
> >>
> >> 024-06-18 08:24:53,696 WARN org.apache.struts2.components.Date Date:end
> >> - Developer Notification (set struts.devMode to false to disable this
> >> message):
> >>
> >> Expression [bean.created] passed to <s:date/> tag which was evaluated to
> >> [null](null) isn't supported!
> >>
> >> On 18/06/2024 08:34, Kusal Kithul-Godage wrote:
> >>> Good questions
> >>>
> >>> The log messages for these are at the debug level so you will need to
> >>> enable logging at the debug level to see these. This was a deliberate
> >>> decision as otherwise bad actors would be able to flood your
> >>> application logs.
> >>>
> >>> The annotations should only target Action class methods. If you are
> >>> using a bean (also known as a form DTO), you only need to annotate the
> >>> getter method on the Action class that returns that bean (and with an
> >>> appropriate depth limit).
> >>>
> >>> If you add `@StrutsParameter(depth = 99)` to every getter/setter
> >>> method on every Action class, it is indeed equivalent to disabling the
> >>> capability entirely.
> >>>
> >>> So the annotation exists to prevent your application users from
> >>> invoking any arbitrary getter/setter on your Action classes as they
> >>> have been able to do in Struts 6 and earlier.
> >>>
> >>> Also feel free to have a read of this section if you haven't had a chance
> >>> too:
> >>> https://struts.apache.org/security/#defining-and-annotating-your-action-parameters
> >>>
> >>> On Tue, Jun 18, 2024 at 5:22 PM Greg Huber<gregh3...@gmail.com> wrote:
> >>>> For the |struts.parameters.requireAnnotations=||true|
> >>>>
> >>>> If I test my action, there are no log messages for these. ie missing
> >>>> @StrutsParameter.
> >>>>
> >>>> It also says Action class, what if I have a bean in the action class, do
> >>>> I need to do these also?
> >>>>
> >>>> If I add them to every field/bean is this the same as setting it false?
> >>>> ie what does @StrutsParameter do?
> >>>>
> >>>> On 18/06/2024 07:44, Kusal Kithul-Godage wrote:
> >>>>> I've fleshed out the Security section of the migration guide. Open to
> >>>>> any feedback on anything that is still unclear.
> >>>>> https://cwiki.apache.org/confluence/x/wYp3EQ
> >>>>>
> >>>>> On Mon, Jun 17, 2024 at 8:14 PM Kusal Kithul-Godage
> >>>>> <kusal.kithulgod...@gmail.com> wrote:
> >>>>>> Ah right - yep no objections here
> >>>>>>
> >>>>>> Based on the feedback in this thread, I'm working on a minor
> >>>>>> enhancement for the allowlisting capability which will allow it to
> >>>>>> continue working at a lesser strictness in environments where
> >>>>>> Hibernate entities are used. I'll target M8 for this as well as the
> >>>>>> updated documentation
> >>>>>>
> >>>>>> On Mon, Jun 17, 2024 at 8:07 PM Lukasz Lenart<lukaszlen...@apache.org>
> >>>>>> wrote:
> >>>>>>> pon., 17 cze 2024 o 11:00 Kusal Kithul-Godage
> >>>>>>> <kusal.kithulgod...@gmail.com> napisał(a):
> >>>>>>>> When you say release officially do you mean as the final Struts
> >>>>>>>> 7.0.0?
> >>>>>>> I meant release -> publish as M7 in the Maven Central - in such a case
> >>>>>>> we can spread testing to other users as they can use official
> >>>>>>> artifacts.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> Lukasz
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe,e-mail:dev-unsubscr...@struts.apache.org
> >>>>>>> For additional commands,e-mail:dev-h...@struts.apache.org
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe,e-mail:dev-unsubscr...@struts.apache.org
> >>>>> For additional commands,e-mail:dev-h...@struts.apache.org
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe,e-mail:dev-unsubscr...@struts.apache.org
> >>> For additional commands,e-mail:dev-h...@struts.apache.org
> >>>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:dev-unsubscr...@struts.apache.org
> > For additional commands, e-mail:dev-h...@struts.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
