Re: Ajax Form submission and method mismatch
On Feb 3, 2018 11:19, "Carl-Eric Menzel" 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 being. 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 >> > >
Re: Ajax Form submission and method mismatch
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 being. 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
Re: Ajax Form submission and method mismatch
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
Re: Ajax Form submission and method mismatch
Ok. I see. On Fri, Feb 2, 2018 at 3:42 PM, Carl-Eric Menzel wrote: > GET requests can be triggered by someone opening a page with e.g. an > image URL pointing to that. In a small application, this URL can be > guessable. > But even if it weren't a security issue - I still would like to know why > there is this inconsistency between onFormSubmitted and > onFormSubmitted(submitter). > > On Fri, Feb 2, 2018, at 15:39, Ernesto Reinaldo Barreiro wrote: > > Ok. But does that posses a real security issue? i.e not logged used > > triggering a click on "that" button that does not exists for them? > > > > On Fri, Feb 2, 2018 at 3:36 PM, Carl-Eric Menzel > > > wrote: > > > >> You're not wrong, but I'd still like to be able to block GET. And the>> > other question is **why** this check isn't done for forms with submit>> > components (I haven't tried it, but I suspect using a regular button>> > rather than an ajax button would run into the same issue). > >> > >> On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote: > >>> Hi, > >>> > >>> Maybe I'm wrong but for AJAX only logged in user could get that > >>> REQUEST to> work because it is page relative. Or am I completely > >>> wrong?>>> > >>> On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel > >>> > wrote: > >>> > 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 > > >>> > >>> > >>> > >>> -- > >>> Regards - Ernesto Reinaldo Barreiro > >> > >> > > > > > > -- > > Regards - Ernesto Reinaldo Barreiro > > -- Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
GET requests can be triggered by someone opening a page with e.g. an image URL pointing to that. In a small application, this URL can be guessable. But even if it weren't a security issue - I still would like to know why there is this inconsistency between onFormSubmitted and onFormSubmitted(submitter). On Fri, Feb 2, 2018, at 15:39, Ernesto Reinaldo Barreiro wrote: > Ok. But does that posses a real security issue? i.e not logged used > triggering a click on "that" button that does not exists for them? > > On Fri, Feb 2, 2018 at 3:36 PM, Carl-Eric Menzel > > wrote: > >> You're not wrong, but I'd still like to be able to block GET. And the>> >> other question is **why** this check isn't done for forms with submit>> >> components (I haven't tried it, but I suspect using a regular button>> >> rather than an ajax button would run into the same issue). >> >> On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote: >>> Hi, >>> >>> Maybe I'm wrong but for AJAX only logged in user could get that >>> REQUEST to> work because it is page relative. Or am I completely >>> wrong?>>> >>> On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel >>> > wrote: >>> 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 >>> >>> >>> >>> -- >>> Regards - Ernesto Reinaldo Barreiro >> >> > > > -- > Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
Ok. But does that posses a real security issue? i.e not logged used triggering a click on "that" button that does not exists for them? On Fri, Feb 2, 2018 at 3:36 PM, Carl-Eric Menzel wrote: > You're not wrong, but I'd still like to be able to block GET. And the > other question is *why* this check isn't done for forms with submit > components (I haven't tried it, but I suspect using a regular button > rather than an ajax button would run into the same issue). > > On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote: > > Hi, > > > > Maybe I'm wrong but for AJAX only logged in user could get that > > REQUEST to> work because it is page relative. Or am I completely wrong? > > > > On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel > > > wrote: > > > >> 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 > >> > > > > > > > > -- > > Regards - Ernesto Reinaldo Barreiro > > -- Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
You're not wrong, but I'd still like to be able to block GET. And the other question is *why* this check isn't done for forms with submit components (I haven't tried it, but I suspect using a regular button rather than an ajax button would run into the same issue). On Fri, Feb 2, 2018, at 14:45, Ernesto Reinaldo Barreiro wrote: > Hi, > > Maybe I'm wrong but for AJAX only logged in user could get that > REQUEST to> work because it is page relative. Or am I completely wrong? > > On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel > > wrote: > >> 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 >> > > > > -- > Regards - Ernesto Reinaldo Barreiro
Re: Ajax Form submission and method mismatch
Hi, Maybe I'm wrong but for AJAX only logged in user could get that REQUEST to work because it is page relative. Or am I completely wrong? On Thu, Feb 1, 2018 at 10:45 PM, Carl-Eric Menzel wrote: > 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 > -- Regards - Ernesto Reinaldo Barreiro
Ajax Form submission and method mismatch
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
