Bernard created WICKET-6807:
-------------------------------

             Summary: Fake Submitting Button
                 Key: WICKET-6807
                 URL: https://issues.apache.org/jira/browse/WICKET-6807
             Project: Wicket
          Issue Type: Bug
          Components: wicket-core
    Affects Versions: 8.9.0
            Reporter: Bernard


In org.apache.wicket.markup.html.form.Form#findSubmittingButton Wicket tries to 
identify the submitting component by searching IRequestParameters of the 
Request for a GET parameter with a name matching the button's input name.

This fails with a POST form submission from a page that has a GET request 
parameter with the name matching the name of one of multiple submit components 
that is NOT the submitting component. In that case, the method finds the 
parameter of the fake submitting component in the GET parameter list and tries 
to execute the onSubmit() method of the fake submitting component.

We can show this with a test case by making the fake submitting component 
invisible which causes an Exception.

The root cause is that Wicket does not model the HTTP protocol correctly 
because it does not distinguish between POST request headers and GET request 
URL parameters when it searches for the submitting component.

This has already been highlighted in a different case in 2011 at "Confusion 
with Get Parameter Name same as Form Field Name" 
https://issues.apache.org/jira/browse/WICKET-4036.

This new case is not an esoteric case because a page might have an "edit" 
function with an "edit" button that needs to be set invisible by setting a URL 
parameter ?edit=false. The page then makes the "edit" button invisible, and on 
form submission, the page crashes because it incorrectly assumes that the 
"edit" button was the submitting component which it cannot find because it is 
invisible.

To me it appears that Wicket is quite a neat framework because it aims to model 
real things and processes found in web applications in Java, so I think 
modeling HTTP request headers and query parameters correctly would be of high 
value.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to