Third Party Cookies restrictions in browsers like Chrome 80 and later

Third Party Cookies restrictions in browsers like Chrome 80 and later

NOTE - Chrome 90 has enforced the below more than it was in version 80, if this is only just beginning to effect you this will be due to the increased enforcement rather than a further change.
NOTE - the only future proof method below is "Using postMessage Callbacks", the other methods are workarounds and Custom Gateway cannot guarantee these will work or will continue to work.


Starting from version 80 (due to be released early February 2020), Google Chrome will start to enforce much stricter rules on what are known as “Third Party Cookies”. The primary reason for doing so is to improve user privacy on the web and prevent tracking by advertising agencies.

As per the Chromium project timeline linked below, the stricter rules will be gradually rolled out over the lifespan of Chrome 80. We currently believe that not all users will be affected at once.

Whilst we agree that the changes are good for the web in the long term, they unfortunately mean that our traditional add to cart mechanisms in Smartlink Apps will no longer work correctly for users of Chrome.

The change means that when a user clicks “Add to Cart” in a Smartlink app and the Smartlink app subsequently sends a request to the callback URL specified by the eCommerce site, Chrome will no longer send a cookie with that request and the eCommerce site will therefore be unable to identify the user.

This is likely to manifest in two different ways:

  • Sites that are performing CSRF token checks will generally reject the request.
  • Sites that do not have CSRF protection in place will typically create a new cart session for the user rather than adding an item to the existing cart.

More information can be found on the Chrome Platform Status page: https://www.chromestatus.com/feature/5633521622188032 and the Chromium project page: https://www.chromium.org/updates/same-site

The new restrictions can be enabled in advance of them becoming the default by enabling “SameSite by default cookies” and “Cookies without SameSite must be secure” via the chrome://flags URL.

Note: Magento1 and Magento2 sites be can be upgraded to the latest versions of Personalise-iT (1.8.1.0 for M1 and 2.3.2.0 for M2) to workaround cookie restrictions. The rest of this document does not apply to M1 and M2 sites using the latest versions of Personalise-iT.

There are however several ways detailed below in which eCommerce sites using Smartlink apps can work around the issue.

However please bear the following in mind:

  • It may be that your site is already coincidentally using one of the below methods and is therefore unaffected.
  • For some requests, Chrome will make an exception if the cookie is less than 2 minutes old (i.e. since the last Set-Cookie header was received). This could make it appear that your site is unaffected. We recommend leaving more than 2 minutes between loading the Smartlink iframe and clicking “Add to Cart” when testing.
  • The key aspect of methods (2) and (3) is that the parent page (which has access to the user’s session cookie) will be responsible for adding the item to the cart rather than the callback page within the iframe (which doesn’t have access to the user’s session cookie).

#1. SameSite=None

The simplest but least preferable way to ensure that add to cart functionality continues to work is to set the SameSite properties on cookies to “None”. Cookies will also need to be marked as “Secure” (only available in a HTTPS context).

However please bear in mind the following when using this approach:


  1. Using SameSite=None could be flagged as a security risk in the future.
  2. SameSite=None could be phased out completely by browser vendors in the future.
  3. Some platforms and languages such as PHP have only recently gained native support for setting the SameSite property.
  4. SameSite=None is a recent concept and may have browser compatibility issues. A Safari bug in older versions of iOS causes SameSite=Note to be treated the same as SameSite=Strict.
  5. #2. Using postMessage Callbacks

The prefered solution is to switch to using the Smartlink postMessage mechanism which allows the parent page to listen for ADD_TO_CART_CALLBACK events from within the Smartlink iframe.

Once an ADD_TO_CART_CALLBACK event has been detected, the parent page can take appropriate action to add the item to the cart.

More details can be found at https://developers-v2.custom-gateway.net/#postmessage-api

Note: The data structure used in the postMessage mechanism is different to the structure used by the legacy “ep3dUrl” mechanism. If you wish to maintain the same data structure as the legacy mechanism, option (3) might be preferable.

#3. Wrapping legacy callbacks using postMessage

A hybrid approach for those who wish to continue using the legacy “ep3dUrl” callback mechanism is to replace the logic within the callback page with a simple page that communicates item details to the parent page using the postMessage API.

The parent page can then listen for a message from the callback page and take appropriate action to add the item to the user’s cart.

It is important to remember that cookies won’t be sent to the callback page by the user’s browser. This will likely cause your callback page to initiate a new session and reply to the browser with a new cookie. Please ensure that this doesn’t happen as it could mean that subsequent requests made by the parent page will use the new cookie rather than the original.

Example code:

Callback page:

<script>

        function getDataFieldFromPost() {

                // Use your server side scripting language of choice to extract the "data" field

                // from the POST request sent to your callback page by the smartlink iframe and

// make it available to client side JS.

                //

                // Don't forget to:

//        - make sure everything is correctly escaped and XSS safe.

                //         - not send any cookies in the response

                return "...";

        }

        window.parent.postMessage({

                name: 'SMARTLINK_ADD_TO_CART_CALLBACK',

                body: JSON.parse(getDataFieldFromPost())

        }, window.location.origin);

</script>

Parent page:

<script>

        function doAddToCart(body) {

                // Trigger the same logic that the original version of your callback URL was performing        

        }

        

        window.addEventListener("message", function(e) {

                if(e.origin == window.location.origin) {

                        var name = e.data.name;

                        var body = e.data.body;

        

                        if(name == 'SMARTLINK_ADD_TO_CART_CALLBACK') {

                                doAddToCart(body);

                        }

                }

        });

</script>

#4. Using a one time token in your legacy callback URL

A completely alternative approach would be to embed a token into your legacy “ep3dUrl” callback URL that uniquely identifies either the session or cart.

Your callback URL should then use said token to determine the current user or cart. As with option (3), the callback URL should not create a new cookie.

Whilst simple to implement, please be aware of the potential security risks with this approach:


  • Take care not to directly expose any sensitive information such as session IDs that could be used to hijack a user’s session.
  • Remember that query parameters are likely to be logged
  • Ensure that the token can only be used once and has a reasonable expiry time.


    • Related Articles

    • Third Party eCommerce Website Plugins

      We have worked with a number of developers who have created plugins to popular ecommerce platforms which can help take some of the work out of setup. These plugins are all directly supported by the developers who created them Prestashop: - Module and ...
    • Setting Up Auto Print for Labels in Google Chrome

      How to Enable "kiosk printing" ( print automatically ) for Google Chrome on Windows Silent printing means printing (particularly receipt printing) 'automatically', either by bypassing the print dialog altogether, or automatically 'printing' when the ...
    • What browsers support Web GL 3D Products for Personalisation?

      Products within our Personalisation Apps can be displayed as either 2D images / drawings, Web GL 3D or Flash 3D Web GL is gradually superseding Flash 3D and is our recommended option - everyday more and more PCs support Web GL To check if your ...
    • What browsers / devices support your Personalisation / Sample Apps

      Unfortunately at the moment there is no such thing as a personaliation or sample app that is supported 100% on every browser or device but we have developed a range of products that cover every possible option - detailed below is a quick overview ...
    • Browsers - Clearing your Cache

      Occasionally, you may come across a situation where you need to clear your browsers cache.  The method used to clear your browsers cache is dependent on the browser that you are running and also the version number of your browser. A step by step ...