RE: [EXTERNAL] Re: Need ResourceReference level placeholders for SRI integrity hashes and CrossOrigin for PCI Compliance

[Michael Pritt <mi...@westringtechnologies.com>]

Thanks, created a pull request for review.

-----Original Message-----
From: Martin Grigorov <mg...@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.pritt@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 ?