General Symptoms
The Spotfire JavaScript Mashup API stops working. There will be a blank page/visualization or possibly a login prompt where the visualization is supposed to be. This is due to cookies not being sent to the server as they have been earlier. This increased security is first introduce in Chrome version 80, released February 2020, but it is expected for other browsers to follow.

Specific symptoms
Below are examples of errors generated in the developer console of the browser, not normally seen by the user:

If TIBCO Spotfire JavaScript (JS) API version 7.14+ is used, the following error is generated in the browsers console, and nothing is shown if not handled in the Portal JS code.
"A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
Status not OK. ERROR: Third party cookies must be allowed for domain 'https://spotfire-next.cloud.tibco.com'."

If TIBCO Spotfire JavaScript API version 7.5, used in 7.11, you get the following error:
"A cookie associated with a cross-site resource at https://spotfireserver.yourdomain.com/ was set without the `SameSite` attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032."
YourHtmlPage.html:19 Uncaught ReferenceError: spotfire is not defined
    at YourHtmlPage.html:19


Why:
1. Chrome version 80 will be released February 2020. Then they will change 2 flags that increase the security. It is possible to revert those changes manually on each browser.*

2. If the Portal/Mashup page uses http or https does not matter. The result/limitations are similar.

3. If the Spotfire server called from Mashup runs on http, they Spotfire server needs to be on the same top level domain as the Portal page.

4. If the Spotfire server uses https and the Portal page use the same top-level domain (.company.com) they are not affected at all.

5. If the Spotfire server runs https and the Portal page has another top level domain, then modifications needs to be done on the Spotfire server. Possible also the Spotfire server needs be patched.

* Under Chrome://flags they will change the following two flags to enable, 'Samesite by default cookies' and 'Cookies without Samesite must be secure'. Change this back to disable to remove the added security (THIS IS NOT SOMETHING WE RECOMMEND).

If the Spotfire server uses http, the top level domain name needs to be the same. In that case no modifications needs to be done.

If the Spotfire server uses uses http and is not using the same top level domain, it needs to be set to use the same top level domain or it will not work.
One workaround is be to add a CNAME in the dns.
If the Portal page is on www.firstdomain.com and the Spotfire server is on the serv.seconddomain.com. If there is a CNAME added in the dns for spotfire.firstdomain.com to the serv.seconddomain.com, then the Mashup API could be reached on spotfire.firstdomain.com instead of on the second domain. The result is that they will end up on the same domain. This of course require that they are authenticated on spotfire.firstdomain.com. It's suggested that you should not use http towards Spotfire server.

If you use https and has the same top level domain there should be no issues.

If you use https and have different top level domains, you should upgrade the Spotfire Server installation to LTS 7.11.9, LTS 10.3.6, 10.8.0, or later mainstream versions to be able to handle cookies differently. This is done by making sure the SameSite=None is sent from the server. It's a limitation in Tomcat, and those Spotfire versions are the first ones with a Tomcat versions able to set the SameSite attribute correctly.

In 10.3.7, 10.8.0 and later versions, follow the instructions in https://docs.tibco.com/pub/spotfire_server/latest/doc/html/TIB_sfire_server_tsas_admin_help/server/topics/samesite_cookie_attribute.html

In 7.11.9 and later 7.11 versions, to disable SameSite cookies you need to find this line in {{tomcat/conf/context.xml}}:
{code:xml}
<CookieProcessor className="com.spotfire.server.security.trust.tomcat.SpotfireRfc6265CookieProcessor" />
{code}
and change it to:
{code:xml}
<CookieProcessor className="com.spotfire.server.security.trust.tomcat.SpotfireRfc6265CookieProcessor" sameSiteCookies="None"/>
{code}

How to verify that the SameSite=None is sent from the server:
1. In your browser, visit your Spotfire server via https (https://spotfire.domain.com).
2. Open developer tool (F12) and press 'Application' on top, press Cookies on left, and then rightclick your site under cookies to choose clear.
3. Now visit your Spotfire server again, and verify that there is a 'None' listed below the SameSite column for your cookies. (XSRF-TOKEN and for 7.14+ also JSESSIONID)

After the cookie-related SameSite changes for increased security in the February 2020 release of Google Chrome, you may encounter issues when using the Spotfire JavaScript Mashup API, if mixing hosts/domains on a web page.

The Chromium Projects, SameSite Updates:

• https://www.chromium.org/updates/same-site

Spotfire JavaScript API Overview:

• https://community.spotfire.com/articles/spotfire/spotfire-javascript-api-overview/