Detect some instances of cookie domain misconfiguration

[asnare]

A fairly common misconfiguration for browser-based endpoints is having an explicit cookie domain set to a domain which doesn't match the site in which the tracking script is loaded. This results in the tracking script loading, but the party and session cookies that it sets can't be subsequently read. As a result every page view looks like a new user and session.

As an enhancement we could detect this in the tracking script during load and throw an exception if it's detected. This assumes that this would be noticed quicker (and presumably fixed) than what currently seems to be the case.

[cameronbraid]

Some guidelines on how to setup cookies would be appreciated.

For a single domain usage I managed to get it working with :

cookie domain : example.com host page : https://www.example.com script tag https://divolte.example.com/divolte.js

and that works.

However if I want to use that same divolt instance to track www.othersite.com how can I do that ? If I set cookie domain to divolte.example.com each page view is a new session

[friso]

Tracking cookies across multiple second level domains are purposely made impossible by browsers. Typically, you will want to set the cookie domain to .example.com (including the first dot) for tracking across *.example.com (including the naked domain example.com).

If you want to identify users across multiple domains, you have to get them to identify themselves using a login or other means, which in most cases requires some form of explicit consent.

Most workarounds that bypass this protection should likely be considered temporary hacks that browsers will eventually also prevent (e.g. user invisible redirects, etc.). It's unlikely that Divolte will aim to support any of these.