On 4/23/16 2:04 PM, Kristian Waagan wrote:
Den 23.04.2016 22.37, skrev Rick Hillegas:
On 4/23/16 10:07 AM, Kristian Waagan wrote:
Den 23.04.2016 17.50, skrev Bryan Pendleton:
On 4/23/2016 7:20 AM, Rick Hillegas wrote:
Does anyone know what the problem is?
No, I'm not sure, sorry.
I can see that Jenkins build #261 was automatically initiated
after your patch for DERBY-6883 was committed, and the build
job finished with SUCCESS:
https://builds.apache.org/job/Derby-docs/261/
And, in the artifacts of the build, I can see your updated docs:
https://builds.apache.org/job/Derby-docs/261/artifact/trunk/out/ref/rrefsqlj81859.html
But the automatic linkage from "lastSuccessfulBuild" to build 261
doesn't seem to be working, as
https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/index.html
is not showing any content for me, it's just a couple top level
browser frames and a blank screen.
I don't recall any changes to this mechanism recently; is it
possible that this is a problem on the Jenkins side rather than
with your commit?
Hi,
This looks like a problem rooted in CSP (Content Security Policy) -
check your browsers' console.
I can't tell what has made the problem (which is actually a security
feature :)) manifest, i.e. due to changes in web browsers, or how the
HTTP server is setting the HTTP header. Could potentially even be a
Jenkins update.
If you must access the site as it is, there are plugins to disable CSP
in the browser(s).
Regards,
Thanks, Kristian and Bryan. I see the same behavior when using Firefox,
Safari, and Chrome. The Firefox error console reports:
Content Security Policy: Couldn't process unknown directive 'sandbox'
<unknown>
Content Security Policy: The page's settings blocked the loading of a
resource at
https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/toc.html
("default-src 'none'").
That's all Greek to me. Can anyone help parse that output and point a
finger at what is broken (or who should be consulted)?
Based on [1] this looks like a relatively new change in Jenkins.
Infra may have given this some thought, or Jenkins is simply running
with the very restrictive defaults.
I believe you have to get the HTTP headers coming from Jenkins modified
for the current setup to work, and for that you'll need help from
someone with more karma.
If the CSP settings in Jenkins can't be changed (technically or
otherwise), we may have to find another way to host the alpha docs.
Thanks for that information, Kristian. I think that our use of frames is
the offending practice which the CSP setting has intercepted. The
frame-based alpha html docs and public API are both broken. However, the
alpha pdf manuals still work.
If I understand this correctly, we are at risk only if we meet one of
the conditions here:
https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringContentSecurityPolicy-Considerations
. I don't believe that the first condition applies to us ("Are less
trusted users allowed to create or modify files in Jenkins workspaces?")
Only trusted committers can trigger Jenkins builds. I don't know enough
about our Jenkins usage to offer an opinion on the second condition
("Are some slaves not fully trusted?"). Does anyone know the answer to
that question?
Thanks,
-Rick
