On Feb 3, 2018 11:19, "Carl-Eric Menzel" <cmen...@wicketbuch.de> wrote:

I've started working on it.

Incidentally, I just noticed that 6.x which I think is supposed to be
targeting Java 6, can't actually be built with JDK6! The clirr maven plugin
wants to run on at least Java 7. I'm going to work with Java 7 for the time

https://ci.apache.org/builders/wicket-branch-6.x is green.
There we use JDK 1.6 for build, via Maven toolchains.
Do you see any Maven warnings from toolchains plugin complaining that your
configuration doesn't have oracle:jdk16 ?

On 02.02.2018 19:54, Sven Meier wrote:

> Hi Carl-Eric,
> WICKET-4107 was specifically about preventing GET request on stateless
> forms. Why not do something similar for Ajax behaviors?
> Have fun
> Sven
> Am 01.02.2018 um 22:45 schrieb Carl-Eric Menzel:
>> Hi,
>> I've just encountered an interesting oddity. For a normal form
>> submission, there is Form#onMethodMismatch where I can decide what should
>> happen if somebody calls the form's URL with a GET request rather than the
>> usual POST. At least in 6.x and 7.x this is called from onFormSubmitted() -
>> but not from onFormSubmitted(submitter).
>> The result is that for forms that have an ajax button and thus a valid
>> submitter, I can't stop somebody building a GET request and firing that
>> against the button's URL. Theoretically I could override
>> AjaxFormSubmitBehavior's onEvent method, but that doesn't work for ajax
>> buttons, which build their own AjaxFormSubmitBehavior.
>> On one of my current projects the customer is quite security-minded and
>> would like the application to block these GET requests. My question is: Is
>> it intentional that only the regular onFormSubmitted() method checks this?
>> If yes, I'd like to know the reasoning please. If not, I'm going to write a
>> patch to fix this.
>> Or maybe I'm missing something and am going the wrong way entirely. In
>> that case, let me know please.
>> Carl-Eric

Reply via email to