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?
