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.internalRenderJavaScriptReference, 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 ?
