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.
- relates to
-
JENKINS-59849 Spaces don't work in resource root paths
-
- Closed
-
-
JENKINS-59874 Support resource domain
-
- Open
-
- links to
[JENKINS-41891] Serve static files from second domain as an alternative to setting CSP
Labels | New: security |
Link | New: This issue is related to SECURITY-328 [ SECURITY-328 ] |
Link | New: This issue is related to SECURITY-664 [ SECURITY-664 ] |
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. |
Remote Link | New: This issue links to "CloudBees-internal issue (Web Link)" [ 23609 ] |
Now when you say second domain, can you clarify on the expected scope here? Here are some potential scope options:
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).