Additional Configuration for Chrome 80

Issue

When using Google Chrome version 80 or later, you may be unable to sign out of Ephesoft Transact if you are signed in using single sign-on (SSO). Additionally, you may face issues if Transact is embedded in an external application using an iframe element.

This issue can occur in a cross-domain configuration scenario and can affect all versions of Transact.

Background

Starting with Chrome 80, Chrome has made the following changes regarding cookies:

  • All cookies that do not have the SameSite attribute specified are treated by default as if they have SameSite set to Lax.
  • Chrome will only deliver cookies with SameSite set to None if they are also marked as Secure.

What is the SameSite Attribute?

The SameSite attribute is configured when a cookie is set and is used to describe the contexts in which the cookie is available for reading.

There are three possible values for this attribute:

ValueDescription
StrictWhen SameSite=“Strict”, the cookie is only available in requests where the request host shares the public suffix of the request origin.

Cross-site cookies are not allowed. For example, if a page on domain.com requested a resource from www.domain.com, the SameSite=”Strict” cookie would send the resource. But if the page on domain.com requested a resource from example.com, any SameSite=”Strict” cookies written on example.com would not be included in the request.

This applies to navigation as well.

LaxWhen SameSite=”Lax”, the cookie behaves similar to Strict cookies but does allow for top-level navigation to include the cookie in the HTTP headers.

For example, if you navigate from domain.com to example.com, the SameSite=”Lax” cookies written on example.com would be included in the request.

Note: This is the default value for cookies without an explicitly set SameSite attribute.

NoneWhen SameSite=”None”, cookies can be accessed in first-party and third-party contexts without restrictions. This attribute should be used if you have a cookie that must be distributed to multiple domains in HTTP headers.

Important: When the SameSite attribute is set to None, the cookie must also have the Secure flag. Chrome will not accept the Secure flag unless the connection is HTTPS, otherwise, the cookie will be blocked.

Cause

The issues described above may be caused by one or more of the following scenarios:

SSO Provider

Your SSO provider may not have adjusted their solution to accommodate Chrome 80 changes. If you suspect this may be the case, refer to the Solution section below.

CORS Policy

The iframe embedded in Transact may have been blocked by Chrome due to updates to their Cross-Origin Resource Sharing (CORS) policy enforcement. This may occur due to one or more of the following:

  • The public suffix of the host page is different from that of the iframe embedded in Transact.
  • The host page and iframe content are using HTTP, or are mixed content (one is HTTPS while the other is HTTP).
  • The HTTPS certificates are invalid or have expired.

If this applies to you, refer to Run Chrome Without CORS.

Programmatic Handling of iFrame

Recent changes to Chrome may have impacted the programmatic handling of iframes, which may cause Chrome to block the iframe contents. This may occur due to one or more of the following:

  • The iframe src attribute is set using Javascript.
  • The dimension specifications of the iframe in CSS is set as a percentage.

Note: In some cases, changing the dimension specifications from a percentage to fixed has resolved this issue.

If this applies to you, you may need to investigate the iframe source code. Ensure your version of Chrome is up to date, as some issues with how Chrome loads iframes have been resolved in recent versions.

Solution

Most major SSO providers have adjusted their solutions to reflect this change. If you encounter any issues with iframe or SSO authentication, contact your SSO provider or configure your external web application and ensure that:

  • Authentication and authorization-related cookies have SameSite=”None” and the Secure flag is set. Refer to the workaround for cookies listed below.
  • SSO communication is using HTTPS.

Note: Ephesoft Transact currently uses the following four cookies:

  1. sessionExpiry
  2. serverTime
  3. authType
  4. JSESSIONID

Figure 1. Transact Cookies

Workaround 1: Cookies

If the solution mentioned above cannot be applied, we recommend not embedding Transact as an external web application in an iframe. Instead, consider using a pop-out option to launch Transact. If you are unable to do so, you can manually configure the cookies on your instance of Chrome as another workaround.

Note: This should be done for each user’s instance of Chrome that is facing iframe or SSO issues with Ephesoft Transact.

  1. Open the Chrome browser.
  2. Enter the following in the browser’s location bar: chrome://flags/#same-site-by-default-cookies

Figure 2. Navigate to Flags

This will jump to the SameSite by default cookies entry.

  1. From the drop-down to the right side of this setting, select Disabled.

Figure 3. Disable Selected Cookies

  1. You will be prompted to relaunch the browser. Click Relaunch.

Figure 4. Relaunch Chrome

  1. After the browser relaunches, enter the following in the browser’s location bar: chrome://flags/#cookies-without-same-site-must-be-secure

Figure 5. Navigate to Flags

This will jump to the Cookies without SameSite must be secure entry.

  1. From the drop-down to the right side of this setting, select Disabled.

Figure 6. Disable Selected Cookies

  1. You will be prompted to relaunch the browser. Click Relaunch.

Figure 7. Relaunch Chrome

Workaround 2: Run Chrome Without CORS

The CORS policy applies when a page attempts to access resources from domains different from that of the current page. As such, a potential workaround can be to run Chrome without CORS.

  1. Press Win + R to open the Run window.
  2. In the Run window, type “cmd” and click OK.

This will open the command prompt.

Figure 8. Launch Command Prompt

  1. Enter the following command to launch Chrome with the –disable-web-security flag:
“[Chrome_Installation_Path]\chrome.exe” --disable-web-security

Note: Replace [Chrome_Installation_Path] with the actual location where Chrome is installed. For example:

“C:\Program Files(x86)\Chrome\Application\chrome.exe” --disable-web-security

Figure 9. Disable CORS

Important: To avoid any potential impacts on a regular profile, we recommend first using a temporary folder. To do so, append the above command with the –user-data-dir flag:

“[Chrome_Installation_Path]\chrome.exe” --disable-web-security --user-data-dir=~/chromeTemp

Conclusion

This completes an overview of potential workarounds to the interoperability issues caused by Chrome 80’s new security features, described above.