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 created issue -
          Daniel Beck made changes -
          Labels New: security
          Daniel Beck made changes -
          Link New: This issue is related to SECURITY-328 [ SECURITY-328 ]
          Daniel Beck made changes -
          Link New: This issue is related to SECURITY-664 [ SECURITY-664 ]
          Daniel Beck made changes -
          Description Original: 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 such that accessing that is possible without authentication, just with a token, and that token is used for linked resources as well.
          New: 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.

          Matt Sicker added a comment -

          Now when you say second domain, can you clarify on the expected scope here? Here are some potential scope options:

          • Support multiple domains via multiple web apps (i.e., keep Jenkins as one war, and have another war for handling static assets and access control)
          • Support multiple domains via fancy Apache configs
          • Support multiple domains where the static domain uses a dedicated web server like Apache or nginx (along with any config needed to allow for access control)
          • Support multiple domains via CDN

          Another orthogonal concern: using subdomains of the same domain versus completely separate domains (though since many static assets require authorization, the usual benefits of splitting up your CDN domain name from your app domain name don't apply; we still need the cookies).

          Matt Sicker added a comment - Now when you say second domain, can you clarify on the expected scope here? Here are some potential scope options: Support multiple domains via multiple web apps (i.e., keep Jenkins as one war, and have another war for handling static assets and access control) Support multiple domains via fancy Apache configs Support multiple domains where the static domain uses a dedicated web server like Apache or nginx (along with any config needed to allow for access control) Support multiple domains via CDN Another orthogonal concern: using subdomains of the same domain versus completely separate domains (though since many static assets require authorization, the usual benefits of splitting up your CDN domain name from your app domain name don't apply; we still need the cookies).

          Matt Sicker added a comment -

          Oh, I suppose maybe there's a fifth option:

          • VirtualHost-style support in Winstone. Avoids the need for a reverse proxy to combine domains in simple scenarios as well as duplicating the servlet container. I'm not sure if this is viable depending on Winstone/Jetty features.

          Matt Sicker added a comment - Oh, I suppose maybe there's a fifth option: VirtualHost-style support in Winstone. Avoids the need for a reverse proxy to combine domains in simple scenarios as well as duplicating the servlet container. I'm not sure if this is viable depending on Winstone/Jetty features.

          Matt Sicker added a comment -

          Another option: when using Kubernetes, this is just an exercise in devops to rewrite ingress rules based on paths.

          Matt Sicker added a comment - Another option: when using Kubernetes, this is just an exercise in devops to rewrite ingress rules based on paths.
          Jesse Glick made changes -
          Remote Link New: This issue links to "CloudBees-internal issue (Web Link)" [ 23609 ]

          Daniel Beck added a comment - - edited

          This is specifically about the functionality in DirectoryBrowserSupport that is affected by CSP from SECURITY-95 and breaks many plugins that follow the (anti)pattern of archiving a bunch of HTML files, then serving them via DirectoryBrowserSupport. We even had plugins programmatically disable CSP protection (SECURITY-309).

          Ideally we figure out a way for Jenkins/Stapler to respond differently for a different domain ( Host header) and implement something like github.com/githubusercontent.com on that domain.

          Ideally one DirectoryBrowserSupport would correspond to one random prefix (necessary since there would be no auth on the second domain to hijack), to not break relative links within a set of archived files, such as an archived set of Javadoc HTML files.

          Daniel Beck added a comment - - edited This is specifically about the functionality in DirectoryBrowserSupport that is affected by CSP from SECURITY-95 and breaks many plugins that follow the (anti)pattern of archiving a bunch of HTML files, then serving them via DirectoryBrowserSupport . We even had plugins programmatically disable CSP protection (SECURITY-309). Ideally we figure out a way for Jenkins/Stapler to respond differently for a different domain ( Host header) and implement something like github.com/githubusercontent.com on that domain. Ideally one DirectoryBrowserSupport would correspond to one random prefix (necessary since there would be no auth on the second domain to hijack), to not break relative links within a set of archived files, such as an archived set of Javadoc HTML files.

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

              Created:
              Updated:
              Resolved: