Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
9.16.0
-
None
-
None
-
Rhel 8, with Docker, Java 17 OpenJdk Adoptium
Description
Related to SubmitLinks we now see this javascript being generated on the page in Wicket 9:
<script type="text/javascript">/<![CDATA[/Wicket.Event.add(window, "domready", function(event) { Wicket.Event.add('id6', 'click', function(event)
{ var f = document.getElementById('id5');document.getElementById('id5_hf_0').innerHTML += '<input type="hidden" name="components/redeemSubmitLink" value="x" />';Wicket.Event.fire(f, 'submit');return false;;});;Wicket.Event.publish(Wicket.Event.Topic.AJAX_HANDLERS_BOUND);;});/]]>/</script>
However, we have two instances where this is breaking existing code:
A) In the case of having rolled out own CSP already in Wicket 8, migrating to Wicket 9 and turning off CSP for the app through the following:
public void init() {
getCspSettings().blocking().disabled();
}- {{}}
This still results in the above javascript being generated into the page and being blocked by our inhouse CSP. We don't want the above javascript added to the page at all.
{{}}
B) In the case of using intensive jquery already on pages, with CSP turned on in Wicket 9, our existing jquery scripting can't fire because of this code is on the page. The custom jquery code is already dealing with Nonce values and adding its own event handlers to the components on the page. So this is sort of a hybrid CSP approach. But we cannot avoid using this approach with jquery/nonce/eventhandlers as it's done in jquery at another company which maintains the jquery side and we maintain the wicket side.
Again, we don't want the above javascript added to the page at all.
{}For both cases we attempted to use setDefaultFormProcessing(false); however that results in no form submission at all.
We probably just don't know what APIs to call to get Wicket to act like we need it to.
{{}}
{}already are using jquery and other scripting