-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 2.228
htmlpublisher v1.22
Google Chrome is about to change behavior for cookies without a SameSite attribute, see https://web.dev/samesite-cookies-explained/ and https://www.chromium.org/updates/same-site. The rollout, originally planned for February/March, has now been postponed until the summer. Other browsers will eventually ship the same changes.
We're using the HTML Publisher plugin to publish LCOV-generated code coverage reports. The new SameSite behavior described above, together with the default Content-Security-Policy header, seems to break this use case. Specifically, the cookies set by Jenkins don't include a SameSite attribute and therefore are no longer being sent by the browser when the HTML report page tries to load additional resources (CSS and images), because they are considered cross-site requests. And without the session cookie, these requests are rejected by Jenkins with an HTTP 403 error.
Removing "sandbox" from the default hudson.model.DirectoryBrowserSupport.CSP setting works around the issue, but seems less than ideal.
Hi r2b2_nz, the problem is probably not the HTML Publisher but the way Jenkins produces the cookies. The plugin just serves the files, I guess. But if there are CORS requests from the browser, and the cookie would need to be sent back to Jenkins, then Chrome will refuse to do that. This can happen with any kind of CORS requests: css, script, xhr... It kind of depends on the Jenkins settings, of course, as the fault can only be activated if CORS requests are allowed by the server settings.
In general, as the cookie is produced by Jenkins, this should be moved to be a Jenkins core issue. But as such, it should be high priority as gradually this will cause more problems as new Chrome versions roll out. Currently, in cases where "smart" HTML reports are used, this can cause complete shutdown of some functionalities.