Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-41891

Serve static files from second domain as an alternative to setting CSP

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • jenkins-2.200

      Dealing with Content-Security-Policy is just too annoying, and there's too many plugins trying to just serve static files in Jenkins, often for no real reason.

      We need second domain support for static resources (DirectoryBrowserSupport) such that accessing that is possible without authentication, just with a token, and that token is used for linked resources as well.

          [JENKINS-41891] Serve static files from second domain as an alternative to setting CSP

          Daniel Beck added a comment -

          On second thought, there's no need to encrypt anything here – we don't need to keep the content secret. We just need to confirm it hasn't been tampered with, i.e. users don't get to define their own resource URLs. So what we need is a signature.

          Daniel Beck added a comment - On second thought, there's no need to encrypt anything here – we don't need to keep the content secret. We just need to confirm it hasn't been tampered with, i.e. users don't get to define their own resource URLs. So what we need is a signature.

          Matt Sicker added a comment -

          An HMAC essentially, yes. That sounds fine. These are like super limited use JWTs.

          Matt Sicker added a comment - An HMAC essentially, yes. That sounds fine. These are like super limited use JWTs.

          Daniel Beck added a comment - Plugins affected: https://wiki.jenkins.io/display/JENKINS/Acunetix+Plugin https://wiki.jenkins.io/display/JENKINS/BTC+EmbeddedPlatform https://wiki.jenkins.io/display/JENKINS/HTML+Publisher+Plugin https://wiki.jenkins.io/display/JENKINS/Javadoc+Plugin https://wiki.jenkins.io/display/JENKINS/LoadRunner+Integration https://wiki.jenkins.io/display/JENKINS/Micro+Focus+Application+Automation+Tools https://wiki.jenkins.io/display/JENKINS/NeoLoad+Plugin https://wiki.jenkins.io/display/JENKINS/PRQA+Plugin https://wiki.jenkins.io/display/JENKINS/Redmine+Metrics+Report+Plugin https://wiki.jenkins.io/display/JENKINS/VectorCAST+Execution+Plugin https://wiki.jenkins.io/display/JENKINS/Worksoft+Certify+DashBoard+Plugin https://wiki.jenkins.io/display/JENKINS/Worksoft+Certify+Process+Runner https://wiki.jenkins.io/display/JENKINS/Worksoft+Certify+Process+Suite https://wiki.jenkins.io/display/JENKINS/Worksoft+Certify+RiskBased+PlugIn More in comments on https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy

          Matt Sicker added a comment -

          Not sure how relevant it would be, but the Audit Log plugin makes HTML audit logs available via DirectoryBrowserSupport. If I wanted to use more advanced UI pages for that, it would likely need its own CSP.

          Matt Sicker added a comment - Not sure how relevant it would be, but the Audit Log plugin makes HTML audit logs available via DirectoryBrowserSupport. If I wanted to use more advanced UI pages for that, it would likely need its own CSP.

          danielbeck I think resource root url docs could be improved adding simple example for reverse proxy setup using nginx/apache 

          Joseph Petersen (old) added a comment - danielbeck I think resource root url docs could be improved adding simple example for reverse proxy setup using nginx/apache 

          Sagar added a comment -

          Hi All, we are using a performance tool that generated html content based on the jinja templates and we want to publish those inside Jenkins.

          The html content is not displayed properly, I understand that its due to Content Security Policy. When I tried to run some commands like System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", ""), still the html content is not displayed properly. Does it need a jenkins restart ?
          Now here comes the question of resoure root URL. I have these files generated and archived inside the Jenkins workspace. What should be the URL I need to provide ?
          When I open the html in the browser its pointing to the location in which its present but not any particular website.

          Can some one please help ?

          Sagar added a comment - Hi All, we are using a performance tool that generated html content based on the jinja templates and we want to publish those inside Jenkins. The html content is not displayed properly, I understand that its due to Content Security Policy. When I tried to run some commands like System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", ""), still the html content is not displayed properly. Does it need a jenkins restart ? Now here comes the question of resoure root URL. I have these files generated and archived inside the Jenkins workspace. What should be the URL I need to provide ? When I open the html in the browser its pointing to the location in which its present but not any particular website. Can some one please help ?

          Kalle Niemitalo added a comment - - edited

          I don’t think changing the property value needs a Jenkins restart. DirectoryBrowserSupport rereads it every time: https://github.com/jenkinsci/jenkins/blob/f48c5f552f72485658c1c98482b42ae42ed1ee8c/core/src/main/java/hudson/model/DirectoryBrowserSupport.java#L380

          You could use the developer features of the web browser to check whether the HTTP response still has a Content-Security-Policy header and what kind.

          Kalle Niemitalo added a comment - - edited I don’t think changing the property value needs a Jenkins restart. DirectoryBrowserSupport rereads it every time: https://github.com/jenkinsci/jenkins/blob/f48c5f552f72485658c1c98482b42ae42ed1ee8c/core/src/main/java/hudson/model/DirectoryBrowserSupport.java#L380 You could use the developer features of the web browser to check whether the HTTP response still has a Content-Security-Policy header and what kind.

          Sagar added a comment -

          kon Thank for your response. I was also looking at second option of configuring resource root url. But what is the resource root URL. for the html files which were generated and available in Jenkins workspace ?

          To keep it simple, how to generate the resource root URL for static files or html files present in the Jenkins workspace ?

          Sagar added a comment - kon Thank for your response. I was also looking at second option of configuring resource root url. But what is the resource root URL. for the html files which were generated and available in Jenkins workspace ? To keep it simple, how to generate the resource root URL for static files or html files present in the Jenkins workspace ?

          Kalle Niemitalo added a comment - - edited

          I don’t really have experience with the resource root URL setting, but from what I understand, you don’t “generate” it; rather, you register another hostname in DNS, pointing to your Jenkins controller host, and configure that as the resource root in Jenkins. Then when a user tries to access “untrusted” files (such as files in workspaces) with a Web browser, Jenkins redirects to a URL within the resource root and serves the file from there.

          So, you should talk about the resource hostname with the people who maintain your DNS. They might decide that you need to use a separate second-level domain (like GitHub has github.com for its own UI but githubusercontent.com for untrusted files). Jenkins does not mandate such a strict separation and would be happy with a subdomain for the resources, but perhaps your corporate network has some other web servers that need to be protected from potentially malicious scripts in untrusted files that Jenkins serves under the resource root URL.

          Kalle Niemitalo added a comment - - edited I don’t really have experience with the resource root URL setting, but from what I understand, you don’t “generate” it; rather, you register another hostname in DNS, pointing to your Jenkins controller host, and configure that as the resource root in Jenkins. Then when a user tries to access “untrusted” files (such as files in workspaces) with a Web browser, Jenkins redirects to a URL within the resource root and serves the file from there. So, you should talk about the resource hostname with the people who maintain your DNS. They might decide that you need to use a separate second-level domain (like GitHub has github.com for its own UI but githubusercontent.com for untrusted files). Jenkins does not mandate such a strict separation and would be happy with a subdomain for the resources, but perhaps your corporate network has some other web servers that need to be protected from potentially malicious scripts in untrusted files that Jenkins serves under the resource root URL.

          Daniel Beck added a comment -

          This is an issue tracker, please ask development questions on the dev list to a much larger audience.

          Daniel Beck added a comment - This is an issue tracker, please ask development questions on the dev list to a much larger audience.

            danielbeck Daniel Beck
            danielbeck Daniel Beck
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: