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

Upcoming Chrome SameSite policy change will break HTML Publisher plugin

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • htmlpublisher-plugin
    • 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.

          [JENKINS-61925] Upcoming Chrome SameSite policy change will break HTML Publisher plugin

          Davide Pesavento created issue -

          Thanks for the report and apologies for the delay in responding. With all that's going on in the world it's taking a while to get to things

          I'll take a look at this as soon to see the impact and what fixes are possible. In the meantime do you happen to know what month "summer" is in the context of the announcement? I assume it means US summer so if happen to be able to clarify when that is for non-US resident that'd be great

           

          Richard Bywater added a comment - Thanks for the report and apologies for the delay in responding. With all that's going on in the world it's taking a while to get to things I'll take a look at this as soon to see the impact and what fixes are possible. In the meantime do you happen to know what month "summer" is in the context of the announcement? I assume it means US summer so if happen to be able to clarify when that is for non-US resident that'd be great  

          Davide Pesavento added a comment - - edited

          That's all the announcement says: "we’re now aiming for over the summer". I don't have any more specific info. And yes, I think we can assume it means northern hemisphere summer, so June to September.

          Also note that "Non-stable Chrome channels (e.g. Dev, Canary, and Beta) will continue with 50% enablement in Chrome 80 and later". I'm able to reproduce the problem with Chrome 83 beta (I guess I'm one of the "lucky" 50%).

          Davide Pesavento added a comment - - edited That's all the announcement says: "we’re now aiming for over the summer". I don't have any more specific info. And yes, I think we can assume it means northern hemisphere summer, so June to September. Also note that "Non-stable Chrome channels (e.g. Dev, Canary, and Beta) will continue with 50% enablement in Chrome 80 and later". I'm able to reproduce the problem with Chrome 83 beta (I guess I'm one of the "lucky" 50%).

          Thanks pesa - if the there's nothing particular sensitive about the calls being made, just wondering if you would be able to share a HAR file (see e.g. https://support.zendesk.com/hc/en-us/articles/204410413-Generating-a-HAR-file-for-troubleshooting for details if you aren't sure how) to record the requests & responses so I can get an idea about what is being passed when the 403 is returned etc. Also a copy of any errors in the browser console would be useful too.

          The Chrome changes relate to cookies and HTML Publisher itself doesn't really do anything special with cookies and so I'm just wanting to try and get more info so that I can work out if this is something in my realm to fix or if I'll have to kick it over to Jenkins Core developers.

          Richard Bywater added a comment - Thanks pesa - if the there's nothing particular sensitive about the calls being made, just wondering if you would be able to share a HAR file (see e.g. https://support.zendesk.com/hc/en-us/articles/204410413-Generating-a-HAR-file-for-troubleshooting for details if you aren't sure how) to record the requests & responses so I can get an idea about what is being passed when the 403 is returned etc. Also a copy of any errors in the browser console would be useful too. The Chrome changes relate to cookies and HTML Publisher itself doesn't really do anything special with cookies and so I'm just wanting to try and get more info so that I can work out if this is something in my realm to fix or if I'll have to kick it over to Jenkins Core developers.

          Facundo Mateo added a comment -

          Hi everyone, 

          A couple of days ago my chrome instalation updated to version 84.0.4147.105.  Since then It is not possible to watch published Open Clover report from Jenkins. 

          I get 403 response for external resources as css and js. 

          Chrome console states:

          "Because a cookie's {{SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which prevents the cookie from being sent in a cross-site request. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.}}Resolve this issue by updating the attributes of the cookie:

          • Specify {{SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.}}
          • Specify {{SameSite=Strict or SameSite=Lax if the cookie should not be sent in cross-site requests"}}

          Facundo Mateo added a comment - Hi everyone,  A couple of days ago my chrome instalation updated to version 84.0.4147.105.  Since then It is not possible to watch published Open Clover report from Jenkins.  I get 403 response for external resources as css and js.  Chrome console states: "Because a cookie's {{SameSite  attribute was not set or is invalid, it defaults to  SameSite=Lax , which prevents the cookie from being sent in a cross-site request. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.}} Resolve this issue by updating the attributes of the cookie: Specify {{SameSite=None  and  Secure  if the cookie should be sent in cross-site requests. This enables third-party use.}} Specify {{SameSite=Strict  or  SameSite=Lax  if the cookie should not be sent in cross-site requests"}}

          Thanks for the message mateofacu - is it possible to try and share some details about what cookie(s) are being affected in your install? As per my previous message HTML Publisher doesn't do anything special with cookies so would be good to determine if its specific to the use-case you are using or whether its a Jenkins core issue (or both )

          Richard Bywater added a comment - Thanks for the message mateofacu - is it possible to try and share some details about what cookie(s) are being affected in your install? As per my previous message HTML Publisher doesn't do anything special with cookies so would be good to determine if its specific to the use-case you are using or whether its a Jenkins core issue (or both )

          Andras Kovi added a comment -

          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.

          Andras Kovi added a comment - 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.

          Thanks akovi. I'm trying to get my head around it (my head is currently also in another space so trying to bounce between the two ) so slowly getting there.

          It seems to me that the issue isn't actually with Jenkins itself but with the cookies being served from third-party sites that are linked to from the HTML that is being published via Jenkins. Does that seem an accurate assessment? It would be useful if someone can confirm that (you can see which cookies are being blocked in the Developer Tools "Issues" tab)

          If that's the case then there still is the issue that even if it sends through a "Lax" setting it still probably won't send the cookie as only "None" will work when in an iframe but if I can at least determine that I'm on the right track then I know where to focus my efforts.

          Richard Bywater added a comment - Thanks akovi . I'm trying to get my head around it (my head is currently also in another space so trying to bounce between the two ) so slowly getting there. It seems to me that the issue isn't actually with Jenkins itself but with the cookies being served from third-party sites that are linked to from the HTML that is being published via Jenkins. Does that seem an accurate assessment? It would be useful if someone can confirm that (you can see which cookies are being blocked in the Developer Tools "Issues" tab) If that's the case then there still is the issue that even if it sends through a "Lax" setting it still probably won't send the cookie as only "None" will work when in an iframe but if I can at least determine that I'm on the right track then I know where to focus my efforts.
          Andras Kovi made changes -
          Attachment New: screenshot-1.png [ 52123 ]

          Andras Kovi added a comment -

          r2b2_nz the HTML running in the iframe starting requests toward Jenkins are the problematic ones as these requests do include the cookie. External sites and their cookies are not in play here. Jenkins must produce a cookie that conforms to the new rules. For example, an HTML containing a reference to a CSS, like so:

          <head>
              <link rel="stylesheet" href="css/materialize.min.css">
          <head>
          Text

          The request for the css will fail with the message mentioned earlier. The cookie is mandatory as it contains the authentication info. Here is a screenshot:

          Andras Kovi added a comment - r2b2_nz the HTML running in the iframe starting requests toward Jenkins are the problematic ones as these requests do include the cookie. External sites and their cookies are not in play here. Jenkins must produce a cookie that conforms to the new rules. For example, an HTML containing a reference to a CSS, like so: <head> <link rel= "stylesheet" href= "css/materialize.min.css" > <head> Text The request for the css will fail with the message mentioned earlier. The cookie is mandatory as it contains the authentication info. Here is a screenshot:

            r2b2_nz Richard Bywater
            pesa Davide Pesavento
            Votes:
            8 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: