[
https://issues.apache.org/jira/browse/WICKET-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860819#comment-17860819
]
John Tal commented on WICKET-7113:
----------------------------------
[~reiern70] [~mgrigorov] -
The question is really, very, very simple. With Wicket 9, Wicket has crossed
into heavy use of Ajax as part of mainline processing (Submit button).
In Wicket 8 this Java script was not being created:
<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>
At the enterprise level, ourselves and other companies became reliant on 3rd
party javascript solutions for advanced client side (javascript validation).
We observe that with Wicket 9 that the framework has now crossed into the
javascript space for it's core function. Wicket is now fighting against other
javascript frameworks with no accomodation to recognize these other frame works.
WE are asking how can we either turn off this javascript OR inject our nonce
into it:
*<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>*
This is not just a code-level issue, it's a framework design issue. Who
behind the design of Wicket 9 and the decision to cross over into
Javascript/Ajax space as a core part of the framework (Submit button) can we
engage here?
> 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)
