Skip to main content
Mitratech Success Center

Chrome - Cross-Site Cookie Change

Chrome has announced a browser update, to be included in the Chrome 80 release, scheduled for February 2020*. The version will change the default cross-site behavior of cookies. It has the potential to impact federated login flows, multiple domains, or cross-site embedded content. Other areas of concern include iframes, 3rd party integration and ajax calls.

*Firefox and Internet Explorer will also release a similar fix in the near future.

The SameSite cookies change explained:

SameSite” is a reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks, but developers currently need to opt-into its protections by specifying a SameSite attribute. In other words, developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default while allowing sites that require state in cross-site requests to opt-in to the status quo’s less-secure model. In addition, forcing sites to opt-in to SameSite=None gives the user agent the ability to provide users more transparency and control over tracking.”


Chromium Blog

Chrome Platform Status

Impact to TeamConnect

TeamConnect General

Out of the box, this change will not affect TeamConnect. However, there may be client customizations in place that rely on cross-site cookies.

TeamConnect Business Intelligence (Sisense Integration)

TeamConnect uses iframes to integrate Sisense dashboards. The new Chrome release would likely impact that functionality if the TeamConnect server and the Sisense server are installed on separate domains (not common). If a user encounters this new security, their dashboard will not display and they will be presented with an error message such as “A cookie associated with a cross-site resource was set without the ‘SameSite attribute’”.

To avoid problems with TeamConnect Business Intelligence caused by this new cookie behavior follow these steps published by Sisense:

For versions 6.7.1 and later until version 7.2 (not including version 7.2) - TeamConnect 6.0+ works with Sisense - a manual process is provided.  The process is relevant for all Sisense deployments, including those using a load balancer, or SSL/TLS termination proxy. Contact your IT Administration for details on your Server configuration and to execute the changes described below.

The following manual steps are available to handle the Chrome changes:

  1. Configure the system to use HTTPS. Instructions to configure HTTPS security can be found here.

  2. Define Cookie Security according to the instructions in the documentation here.

  3. Manually update the Web.Config file located at: C:\Program Files\Sisense\PrismWeb as follows:

    1. In the <system.web> element, add the following element to set the Secure flag on an ASP.NET Session Cookie:
        <httpCookies requireSSL="true" />

    2. In the <system.webServer> <rewrite> element, add the following elements with SameSite=None (to allow cross-domain embedding) or SameSite=Lax value.


      <clear />

      <rule name="Add SameSite" preCondition="No SameSite">

        <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />

        <action type="Rewrite" value="{R:0}; SameSite=None" />



        <preCondition name="No SameSite">

          <add input="{RESPONSE_Set_Cookie}" pattern="." />

          <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=None" negate="true" />




    1.  Replace <anonymousIdentification cookieless="UseCookies" enabled="true" /> by <anonymousIdentification cookieless="UseCookies" enabled="true" cookieRequireSSL="true"/>

  1. Manually update authCookieRequireSsl key the <securityConfiguration> element in security.config file located at C:\Program Files\Sisense\PrismWeb\App_Data\Configurations as follows:


  1. Logout all users by removing the device key in the user's DB model. After login, every user will get a new cookies with correct values. 


If you have embedded dashboards inside a TeamConnect homepage or tab and are using a link that is HTTP, you must update it to HTTPS if you change your server security to SSL/TLS, per the recommendation above.

These fixes have been verified to work with the Okta SSO provider. They do not yet work for the OneLogin SSO provider, as OneLogin has not yet added support for the SameSite cookie option, which will be required by Google Chrome version 80.  We expect OneLogin to be adding this support shortly, as the issue will affect many of their other customers.

Additional Help

If you follow these instructions and run into issues, please contact via the Support Portal.

  • Was this article helpful?