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

    • Kornit Web To Print (W2P) Workflow

      Introduction We produced a workflow which allows items in our platform to be managed and fed into kornit printers and out to couriers in an easy barcode driven workflow. This workflow takes into account all parts of the production cycle Setting up ...
    • Smartlink Apps | Pluto 3

      Introduction The following article has been written to detail how our standard Pluto app can be set up and used for. We have also detailed all of the available features associated with Pluto general, features and styling menus. The point of Pluto is ...
    • Smartlink Apps | Proof3

      Introduction The following article has been written to detail how our standard Proof 3 app can be set up and used for. We have also detailed all of the available features associated with Proof 3 features. This app is designed for the B2B market and ...
    • Smartlink Apps | Digital3

      Introduction The following article has been written to detail how our standard Digital 3 app can be set up and used for. We have also detailed all of the available options associated with Digital 3 features, styling, renderer option and miscellaneous ...
    • Smartlink Apps | Ceres

      Introduction The following article has been written to detail how our standard Ceres app can be set up and used for. We have also detailed all of the available options associated with Ceres features, styling, renderer option and miscellaneous menus. ...