[
https://issues.apache.org/jira/browse/WICKET-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860835#comment-17860835
]
Emond Papegaaij commented on WICKET-7113:
-----------------------------------------
[~bodhione] In versions prior to Wicket 9, the Javascript was also added, but
it was rendered as an inline onclick attribute, which was added to the DOM.
This obviously does not work very well in combination with a CSP. Therefore,
the decision was made to move all these inline Javascript snippets to the HEAD
using proper event handling.
If you do not wish to use the submit handling provided by {{SubmitLink}}, then
don't use {{SubmitLink}}. Create your own subclass of {{AbstractSubmitLink}}.
That should work just fine. {{SubmitLink}} needs this piece of Javascript to
make it work in all situation, and has had this piece of Javascript since its
inception (yes, since the very first commit that created the class).
> Wicket Ajax domReady colliding with existing scripting
> ------------------------------------------------------
>
> Key: WICKET-7113
> URL: https://issues.apache.org/jira/browse/WICKET-7113
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 9.16.0
> Environment: Rhel 8, with Docker, Java 17 OpenJdk Adoptium
> Reporter: John Tal
> Priority: Major
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
