https://issues.apache.org/jira/browse/WICKET-6844
I've decided to implement it at AbstractDefaultAjaxBehavior so almost all
Ajax behaviors could make use of it.
On Mon, Oct 19, 2020 at 8:21 PM Sven Meier <s...@meiers.net> wrote:
> +1 that's a good proposal
>
> Sven
>
>
> On 19.10.20 12:33, Maxim Solodovnik wrote:
> > +1
> >
> > On Mon, 19 Oct 2020 at 17:28, Martin Grigorov <mgrigo...@apache.org>
> wrote:
> >
> >> Hi Eric,
> >>
> >> You can implement it yourself:
> >>
> >> In #onUpdate(AjaxRequestTarget) start with:
> >>
> >> AjaxRequestAttributes attrs = getAttributes();
> >> String desiredMethod = attrs.getMethod().toString();
> >> String actualMethod = ((HttpServletRequest)
> >> RequestCycle.get().getRequest().getContainerRequest()).getMethod();
> >> if (!desiredMethod.equalsIgnoreCase(actualMethod)) {....}
> >>
> >> @devs: What do you think about adding the above to
> >> AjaxFormComponentUpdatingBehavior#onEvent() ?
> >> We can add #onMethodMismatch() to AjaxFormComponentUpdatingBehavior
> that is
> >> similar to one in Form. If it returns ABORT then we will execute the
> code
> >> above. If it returns CONTINUE (the default) then no need to calculate
> the
> >> AjaxRequestAttributes
> >>
> >>
> >> On Sun, Oct 18, 2020 at 11:40 PM Sven Meier <s...@meiers.net> wrote:
> >>
> >>> Hi,
> >>>
> >>> with AjaxFormComponentUpdatingBehavior only a single component is
> >>> processed and not the complete Form.
> >>> So method mismatches are not checked.
> >>>
> >>> Have fun
> >>> Sven
> >>>
> >>>
> >>> On 17.10.20 14:34, Eric Hamel wrote:
> >>>> Looking at our implementation, we are using an
> >>> AjaxFormComponentUpdatingBehavior to trigger our data save.
> >>>> Even though we do a have parent form the onSubmit is never called.
> >>>>
> >>>> Is there an alternative to the onMethodMismatch ?
> >>>>
> >>>> —————————
> >>>> Eric Hamel
> >>>> Senior Project Manager
> >>>> Albany Information Technology Group
> >>>> C. 518-698-4503
> >>>>
> >>>>> On Oct 16, 2020, at 4:32 PM, Martin Grigorov <mgrigo...@apache.org>
> >>> wrote:
> >>>>> On Fri, Oct 16, 2020, 23:27 Eric Hamel <dantehick...@gmail.com>
> >> wrote:
> >>>>>> I apologize in advance for my vague question. Our Wicket 8 based
> >>>>>> application was submitted to pen testing from our EISO. While I
> >>> understand
> >>>>>> the finding, I'm not 100% sure I understand the problem nor do I
> know
> >>> how
> >>>>>> to address it.
> >>>>>>
> >>>>>> In one of our complex forms that uses Ajax Calls to automatically
> >>> update
> >>>>>> the DB when the fields lose focus, the tester made the following
> >>> remark:
> >>>>>> Applications accepts GET requests for coded POST Ajax calls –
> >>> parameters
> >>>>>> can be passed in URL
> >>>>>>
> >>>>>> It appears that through his "fuzzer", even though our requests are
> >>> marked
> >>>>>> as POST, it still processes GET requests. Is there a way to enforce
> >>> POST ?
> >>>>>> Is there any way to mitigate this issue globally from a
> configuration
> >>>>>> standpoint ?
> >>>>>>
> >>>>> See Form#onMethodMismatch()
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
