As $SUBJECT states, we’re seeing more CSP-related failures in the 4.0 TCK that I’d like to discuss. Before getting into details, I’m a bit confused as to how the TCK passes on GF, but seems to be failing when we run against WildFly, and users see similar failures in the wild. Should someone have insight there, I’d much appreciate it. :)
[ERROR] Errors:
[ERROR] Tests run: 12, Failures: 0, Errors: 6, Skipped: 6
The mojarra.ael references should not be rendered, given the back ports made.
I’ve traced the execution in my IDE, and I think I’ve found the issue in OutcomeTargetButtonRenderer.encodEnd():
if (!Util.componentIsDisabled(component)) {
NavigationCase navCase = getNavigationCase(context, component);
if (navCase != null) {
String hrefVal = getEncodedTargetURL(context, component, navCase);
hrefVal += getFragment(component);
RenderKitUtils.addEventListener(context, component, null,"click", getOnclick(component, hrefVal));
}
}
In the bolded line, the <script> tag is always rendered unlike in, say, ButtonRenderer, we see code like this:
if (ResourceHandlerImpl.resolveCurrentNonce(context) != null) {
RenderKitUtils.renderOnclickEventListener(context, component, params, null, false);
}
In theory, then, the fix should be in and the TCK should be happy, but clearly something’s awry. Is the non-CSP JS fix insufficient, or is there something else at play WRT TCK runs? Do we know, e.g., if other containers (Weblogic, etc) passing the TCK with 4.0.18? I’m happy to concede that there’s an issue on the WildFly side if that’s the case, but I’m not seeing how that might be. I’m hoping someone can help me get to the bottom of this...
_______________________________________________