Open janmashat opened 4 years ago
It's because of CORS issues (because the backstop report uses inline styles) which are prohibited on your jenkins. I have the same problem.
This can help:
System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")
More information: https://stackoverflow.com/a/46197356/11217161 https://www.jenkins.io/doc/book/security/configuring-content-security-policy/
That is not really a good solution to clear the CSP. Why not fix the generated report to move the inline styles to a css file + load that and put the inline JavaScript to a js file and load that too, that way it should be CSP compatible if at least 'self' is set?
This is all CSP — no CORS issues.
tl;dr — this came up for me the other day, and I'm working out a solution (and pull-request).
I think the quick fix is to relax headers coming from Jenkins for frame-src
, script-src
, and style-src
. Or remove them entirely and [set them via <meta http-equiv>
tag]() in the (customized) report.
The long-term solution requires some refactoring of the BackstopJS reporting application. nonce
, hash
, and moving everything to a custom loader are all possibilities.
I had a feeling this would come up at some point. Wow — CSP is 20 years old?
Another issue a lot of folks will begin running into — injected CSS/JS via onBeforeScript
and onReadyScript
on a server/page with strong "'self'"
policies will fail. Migrating any application or site to more secure CSP will break once-working BackstopJS tests.
@tkrah thanks for reviving this issue.
If anyone comes across this and has use-cases to share, please do.
FWIW — there's some good history in this thread: Page with CSP breaks puppeteer
Following the "Publish HTML reports" instructions detailed here: https://github.com/garris/BackstopJS/tree/master/examples/Jenkins
The resulting page in Jenkins is empty:
I'm assuming this is due to the javascript in the BackstopJS page conflicting with the built-in Jenkins javascript, or other script execution being blocked.