Thanks, created a pull request for review. -----Original Message----- From: Martin Grigorov <mgrigo...@apache.org> Sent: Thursday, February 13, 2025 5:53 AM To: users@wicket.apache.org Subject: [EXTERNAL] Re: Need ResourceReference level placeholders for SRI integrity hashes and CrossOrigin for PCI Compliance
BE CAREFUL: This email originated from outside the organization. Do not click links, open attachments, or enter user credentials, unless you recognize the sender and know the content is safe. BE CAREFUL: On Tue, Feb 11, 2025 at 10:15 PM Michael Pritt < michael.pr...@westringtechnologies.com> wrote: > Hi, we're currently using wicket 10.1.0, and trying to implement SRI > hashes for all the javascript/css modules we use for PCI compliance. It > is easy to create the integrity and cross origin values needed when > the we have the control over the creation of the JavaScriptHeaderItem > or CssReferenceHeaderItem. It becomes much more difficult when there > are resources that are created and then stored in wicket framework > classes (whether we create or the framework that creates these > resource references) and then these resources are used LATER within > the framework which does the actual creation of the header items. > > As an example try setting the integrity hash for the > "wicket-ajax-jquery.js" file which is referenced from the > wicket-core-10.1.0.jar. This resource is created initially through > the WicketAjaxJQueryResourceReference class and used in the > JavaScriptLibrarySettings class. The call getWicketAjaxReference() > inside the JavaScriptLibrarySettings is used by the framework in > various places, and those places create the actual > JavaScriptReferenceHeaderItem > (see OnDomReadyHeaderItem.getDependencies() as an example). If we can > add both an integrity and cross-origin variables to the definition of > a ResourceReference class, those values could then be used in the rendering > of the JavaScriptReferenceHeaderItem. This can be done by overriding the > getIntegrity function, so if the header item's integrity value is not > defined (i.e. null) then use the value defined from the > ResourceReference (same would go for handling the cross-origin). > > The same changes for handling CSS header items, by changing the > function AbstractCssReferenceHeaderItem. internalRenderCSSReference() > to more correctly handle integrity and cross origin values (note that > the below code changes matches what is already being done in > AbstractJavaScriptReferenceHeaderItem.internalRenderJavaScriptReferenc > e, it shouldn't reference the class variables directly but through > their accessor > methods) > > attributes.putAttribute(CssUtils.ATTR_CROSS_ORIGIN, > crossOrigin == null ? > null > : crossOrigin.getRealName()); > > attributes.putAttribute(CssUtils.ATTR_INTEGRITY, integrity); changes > to > > attributes.putAttribute(CssUtils.ATTR_CROSS_ORIGIN, > getCrossOrigin() == null ? > null : getCrossOrigin().getRealName()); > > attributes.putAttribute(CssUtils.ATTR_INTEGRITY, getIntegrity()); > > The above would help in solving the calls by the framework internally > that create the header items, without having to override main > framework classes to support this need. > > In addition to this, another change would be to change the > JavaScriptLibrarySettings.getWicketAjaxReference() to not return a > ResourceReference but instead return a JavaScriptReferenceHeaderItem. > It looks like in all cases we saw, the framework was just taking the > resource reference and creating the JavaScriptReferenceHeaderItem. > Again, that way it will give more control over the actual header reference at > least for > this particular example mentioned above. Note that this wouldn't solve > the other places that use other wicket javascript/css resources. > > Thoughts? Does this sound reasonable and would be something to change > in wicket? > It sounds reasonable to me! Do you want to send a Pull Request ?
