@Starker3 opened this Issue on March 31st 2021

Description of issue:

When using a cookie domain such as .example.com and requiring cookie consent causes cookies for both www.example.com and .example.com to be created when cookie consent is given when using MTM
However, when cookie consent is withdrawn only one set of cookies are deleted (.example.com).
The www.example.com cookies remain including the mtm_cookie_consent cookie which causes .example.com cookies to be recreated when refreshing the page.

Steps to reproduce:

  1. Setup MTM container using the following settings:
    Enable Link Tracking
    Enable Cross Domain Linking
    Require Cookie Consent
    Cookie domain set to .example.com
    Bundle Tracker
    Register As Default Tracker

  2. Visit the page and execute _paq.push(['rememberCookieConsentGiven']);
  3. Refresh the page and check cookies created (There should be cookies for both www.example.com and .example.com when reproducing - in my testing I am using a website with a different subdomain of static.example.com)
    It is expected here that cookies should only be set to .example.com

  4. Execute _paq.push(['forgetCookieConsentGiven']); and refresh the page. Check cookies, there should be cookies that remained for www.example.com:

  5. Refresh the page, it should have recreated the cookies for .example.com:

Expected behaviour:

When not using a cookie domain and having Require Cookie Consent enabled, the Cookie Consent works as expected. It only creates cookies for the subdomain that is being viewed and the cookies are deleted when withdrawing cookie consent.

@tsteur commented on March 31st 2021 Member

@Starker3 can you reproduce this with standard Matomo tracking code alone?

BTW In step 3

Refresh the page and check cookies created (There should be cookies for both www.example.com and .example.com)

I'm not sure why there should be both cookies set. I would probably expect it to be set only one of them. Or not sure what you mean here?

@Starker3 commented on March 31st 2021

@tsteur What I mean is that for reproducing the error there should be cookies for both .example.com and www.example.com
You are correct in that we would expect there to only be one set of cookies for .example.com

The cookies set directly after giving cookie consent are for www.example.com and the .example.com cookies are created after refreshing the page.

I'll try to reproduce using the standard tracking code.

@tsteur commented on March 31st 2021 Member

I'm thinking it might be expected behaviour and it might not even be able to remove static.example.com cookies but it's bit hard to understand as sometimes mentions www. but images show static.

@Starker3 commented on March 31st 2021

@tsteur That's just the subdomain that I was testing on. The actual site I tested is for example: static.example.com (I don't have this site setup to use www)
But I can maybe set that up to make sure it can be done the same way using www
(I've edited the original report above to make this clear)

@Starker3 commented on March 31st 2021

I tested using a subdomain www and the same occurs. Will test using the standard tracker as well shortly.


@Starker3 commented on March 31st 2021

@tsteur I've been able to reproduce this with the standard tracking code with the following added:
_paq.push(["setCookieDomain", ".example.com"]);

Would you like me to recreate this bug report in Core?

@tsteur commented on March 31st 2021 Member

@Starker3 I moved it.

@Starker3 commented on March 31st 2021

FYI - In some cases the cookies left behind are reversed (I.e. in the example above it was the subdomain cookie www.example.com that was not removed)
It seems that having some plugins active or not may cause the other cookies to remain when using _paq.push(['forgetCookieConsentGiven']); (I.e. .example.com instead of www.example.com)

@Starker3 commented on May 28th 2021

Reproducing issue with the standard JS tracker:

The following is required in the tracking code in order to reproduce:

_paq.push(["setCookieDomain", ".example.com"]);

Step 1: Visit the web page from a subdomain (In this example www.)
Step 2: Execute _paq.push(['rememberCookieConsentGiven']); from the console
Step 3: Confirm that cookies were created for the correct subdomain (www. in this example):
Friday-28-05-2021 12-02-48
Step 4: Refresh the page and confirm that cookies for the cookie domain specified is created (.example.com)
Friday-28-05-2021 12-04-19
Step 5: Execute _paq.push(['forgetCookieConsentGiven']); from the console
Only cookies for the cookie domain specified are removed:
Friday-28-05-2021 12-06-33
Step 6: Refresh the page, all cookies that were removed are created again because of the presence of mtm_cookie_consent:
Friday-28-05-2021 12-08-29

This can be reproduced on any subdomain of a website as long as the top level domain is set as the cookie domain. The only required settings are a top level domain set as cookie domain and cookie consent required.

@tsteur commented on May 28th 2021 Member

@Starker3 thanks for this. moved it into 4.4

This Issue was closed on July 15th 2021
Powered by GitHub Issue Mirror