Backport of CSP-related changes#5606
Conversation
|
@arjantijms @BalusC Any thoughts on this? |
|
Thanks for backporting this, first off! Secondly, out of all the changes implemented, I can't seem to find the one addressing the need of Any chance of any of the PR participants to point it out? Thanks in advance for your time! |
|
LGTM :) But why exactly is Issue5576IT disabled? Have you already ran the entire 4.0 TCK on this branch? Did it all pass? (sorry for late response, I was vacationing) |
@fcarriedos Sorry. Work took me away from this for a bit. :) I thought I had ported everything. Can you point to what I missed? Definitely want to make sure we get it all. :) |
|
@jasondlee Thanks for coming back to me on this one! I'm failing to see any specific change to address the issue described below, more specifically in the definition of Please let me know if I missed something, I am looking in the wrong place or any clarification is needed. ContextWhen there is more than one event handler or more than one action per handler, For this to work, the Content Security Policy forces the need for I pushed this reproducer and I'm attaching some screenshots that hopefully help clarifying the issue.
Thanks in advance for your time! 🙇 |
|
@fcarriedos Thanks. I'll give that a look. My backport is, fwiw, a backport of all of the CSP-related changes from 5.x. I don't pretend to understand all of the changes, but I'll try to fix that. :) |
|
I fixed it in 5.0 #5631 @jasondlee you can now backport thas as well into your branch |
Thanks! On it... |
@BalusC Should this be working in the master branch? I built that branch and integrated that impl jar (and the 5.0 API jar) into WildFly locally so I could verify behavior and correctness, but, |
|
That's a separate issue. This was indeed not covered by "first step" work jakartaee/faces#2046 The h:outputScript doesn't yet support the nonce attribute. The renderers don't yet extract the (passthrough) nonce from faces.js or accept a nonce via e.g. context param. This is the next step which needs to be crystallized in jakartaee/faces#1590 |
|
For now .. just use PrimeFaces with CSP enabled (see also its The main incentive for this "first step" is to ensure that Faces 5.0 standard components work flawlessly with PrimeFaces with CSP enabled. This was previously not the case. The next step is indeed to provide a similar thing as |
|
@jasondlee I implemented it in #5644, when building that and the associated Faces branch, then simply add jakarta.faces.ENABLE_CSP_NONCE=true context param to web.xml (and remove the conflicting CspFilter from @softwaresicario's project) You're free to add a com.sun.faces.enableCspNonce context param therefor in 4.0 (see |
|
FYI: 32c4302, this shall also need to be backported. |
|
And this https://github.com/eclipse-ee4j/mojarra/pull/5653/files also needs to be backported. That'll be the final part I think :) |
f5e530c to
5e79df3
Compare
|
There were only a few inconsistencies which I ironed out: d890b5a However, on second thought, I cannot accept the changes to API classes as that contaminates the 4.0 (and 4.1) API. It would basically falsely claim that these exist in 4.0 spec. These constants/methods have to remain impl-specific. Only when merging the changes into 5.0 branch then we can remove the impl-specific changes and rely on real spec/api based impl. In other words, ResourceHandler and ResourceHandlerWrapper have to be reverted, the constants/methods moved into ResourceHandlerImpl and the context parameters to be com.sun.faces prefixed instead of jakarta.faces. I will take care of this with help of Claude. |
This change ensures that generated script elements are not rendered nested inside the element but only after the element as nested script elements violate html spec in case of <a> and <input> elements
Ready for merge :) |
com.sun.faces CSP related context params to jakarta.faces ones along with a deprecated warning
That's a good catch. Thanks for the clean up and the merge. I'll use this PR to create a backport for 4.1. |
|
@jasondlee it's already merged in 4.1: 54720bd |
Even better. Thanks for handling that, and all the help with this PR. :) If there are no objections, I'm going to release an update for both 4.x versions. |
|
TCK job in Eclipse CI is not working since changes in publishing flow due to migration of Sonatype to Maven Central (cc: @arjantijms ) so you need to manually run TCK beforehand for 4.0 as well as 4.1. If TCK passes for you then you only need to execute "build and stage" job (autoPublish flag is currently true so no additional action is needed). |
|
Does this process still apply? https://github.com/eclipse-ee4j/mojarra/blob/master/RELEASE.md |
|
Nope. Only job 1 at Jenkins works. Job 1 currently basically already publishes (because of recently added autoPublish flag in pom.xml). Jobs 2 and 3 don't anymore work (they still rely on Sonatype) and should therefore be skipped. Full TCK should be executed manually at your machine (in confidence). All this is because of the migration from Sonatype Nexus to Maven Central about 8 months ago. From the RELEASE.md this thus means you can skip the following steps:
We still need to catch up the build scripts and RELEASE.md. We never had real time for this. I'll try to delegate this to Claude this week. |
|
How does this draft look? https://github.com/eclipse-ee4j/mojarra/releases/edit/untagged-c5885c388e36ba86436a Not sure I've done that part before :) |
|
LGTM :) |
|
I'm currently testing 4.1.8 release with the new JenkinsFile: https://ci.eclipse.org/mojarra/job/mojarra-release/1/console |
backport, below is Claude's observation:
Under server-side state saving, ServerSideStateHelper.writeState calls
externalContext.getSession(true) at WriteBehindStateWriter.flushToWriter
time. If the rendered output already exceeds the response buffer (e.g.
the CSP backport in 4.0.17 emits an extra
<script>mojarra.ael(...)</script> per command, roughly doubling per-link
bytes), the response is committed before flushToWriter runs,
getSession(true) then fails with `IllegalStateException: Cannot create a
session after the response has been committed`, aborting the render
mid-form, so </form> and the jakarta.faces.ViewState hidden input never
reach the client.
FaceletViewHandlingStrategy already had a pre-render getSession() guard
for exactly this reason, but it was strict-equality on
STATE_SAVING_METHOD_SERVER, which disagreed with the helper-selection
rule in ResponseStateManagerImpl (anything not
STATE_SAVING_METHOD_CLIENT → ServerSideStateHelper). Configurations
where STATE_SAVING_METHOD is unset or contains an unresolved placeholder
(e.g. ${webapp.stateSavingMethod}) silently used the server helper but
skipped the pre-create.
Fix isServerStateSaving() to mirror the helper-selection rule
(!STATE_SAVING_METHOD_CLIENT.equalsIgnoreCase(...)), and tighten the
pre-create to only fire when actually needed: non-transient view, no
existing session, server-side state saving, and the view contains at
least one UIForm (verified via a short-circuit visitTree). This avoids
gratuitous session creation for plain pages that have no form and would
not write state anyway, which previously caused JSESSIONID URL rewriting
side-effects.
Fixes Issue1817IT regression introduced by the CSP backport.
…ses HtmlUnit which doesn't at all like ES6; rewrite faces-uncompressed.js to not anymore use ES6 specific syntax so YUI Compressor can digest it; fix backport regression in runStylesheets (2 lines were dropped?) and ensure this is covered by faces.ajax.test.ts
…e_4.0_tck' into 'make_sure_csp_backport_passes_the_4.1_tck'


Backporting CSP-related changes from 5.x to the 4.0 branch.