Skip to main content
Skip table of contents

Reverse Proxy Solution for Safari

Safari version 16.4+ sets the lifetime of server-set first-party cookies to a maximum of 7 days in the following cases:

  1. The server setting the cookie is behind a CNAME that resolves (at any point) to a third-party host to the website the user is browsing.

  2. The server setting the cookie is set with A/AAAA records that resolve to an IP address (IP4 or IP6) whose first half (first 2 octets) does NOT match the first half of the IP address of the server the website is hosted on.

It is important to remember that only the second case is a challenge with JENTIS since our setup is based around A records and not a CNAME.

Example:

Imagine case A, where a user is accessing the website tracking.example.com. This website resolves to the CNAME “jentis.com” which is not equal to the original “example.com" the user browsed.

In case B, the user is accessing the same website, but in this case, the A-record of tracking.example.com points it to be resolved as IP address 222.222.2.22, while example.com runs on an address of 111.111.1.11 - as you can see, the first half of the addresses are different from each other.

In both cases, the cookies set in the response will expire within 7 days.

A reverse proxy should be hosted by the same server as the webpage’s content to solve this issue. It ensures that cookie lifetime won’t be limited by Safari’s ITP since we can guarantee that at least the first 2 octets of the IP addresses are the same. At the same time, all communication happens between the browser and the customer’s web server.

A reverse proxy is a server positioned between client devices and a web server. It intercepts client requests and forwards them to the web server. Unlike a forward proxy, which assists the client by forwarding its requests to the internet, a reverse proxy supports the web server by managing incoming requests on its behalf.

How does it work?

1-2: Usual browser operation happens, and requesting web page content is carried out:

JENTIS_Revers-Proxy Solution 1.png

3-4: When the visitor lands on a web page with its content already present, a JENTIS tracking code is requested, in this case, from hash.example.com and loaded into the browser. JENTIS provides hash.example.com separately for every DCP container by default. This is a file request; no operations like cookie setting are being done.

JENTIS_Revers-Proxy Solution 2.png

5-6: As an event is being tracked in the browser, all tracking requests are sent to the Reverse Proxy example.com/hash hosted by the customer. The Reverse proxy is a set of server commands provided by JENTIS and implemented by the customer. It receives tracking requests from the browser and forwards them to hash.example.com (the JENTIS server).

As the tracking request reaches hash.example.com (JENTIS server) through the “Reverse-proxy”, it will also send a response to the browser through the “Reverse-proxy” telling the browser to set certain cookies.

JENTIS_Revers-Proxy Solution 3.png

As you can see, every tracking request goes through the reverse proxy (example.com/hash), which is hosted by the same server as the webpage’s content, instead of directly touching the JENTIS server (hash.example.com). This leads the browser to understand that all requests go to the same server, where the web page’s content is hosted, bypassing Safari requirements.

How to set it up?

In addition to the normal JENTIS setup, there are a few extra steps so that the Reverse Proxy solution can track.

Actions to take on Web Server

  1. JENTIS provides the Reverse Proxy script, a set of server commands that should run on the web page’s server. We use this script to track user behavior. Please get in touch with Customer Support through our Helpdesk to get your individualized script for all JENTIS DCP containers you use.

    Here is an example reverse-proxy script for the Apache Web server.

    CODE
    SSLCertificateFile /something/something/example.com/fullchain.pem
    SSLCertificateKeyFile /something/something/example.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLProxyEngine On
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    ProxyPreserveHost Off
       <Proxy *>
          Require all granted
       </Proxy>
    ProxyPassMatch    /hash(.*) https://hash.example.com$1
    ProxyPassReverse /hash https://hash.example.com/

    example.com is your web server’s domain.
    hash.example.com is the subdomain you created and directed to JENTIS servers with an A-record, to which all tracking requests are sent.

  2. Make sure that the script is running under the correct web server.

Actions to take on the JENTIS DCP

  1. Add a code snippet to your JENTIS DCP, assign the correct container, and execute the code using the “Before Jentis Bundle Load“ trigger. Example:

    CODE
    if(
      typeof window.jentis !== "undefined" &&
      typeof window.jentis.config !== "undefined" &&
      typeof window.jentis.config.trackdomain !== "undefined"
    ){
      window.jentis.config.trackdomain = "https://example.com/hash";
    }

    image-20240531-103440.png

  2. Publish the latest version of the correct container to make the recently added code snippet run.


If you have any questions or suggestions, contact us through our Helpdesk.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.