Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setting the cookie domain even when cookies are disabled for compatibility with "Require Cookie Consent" feature #17417

Closed
Starker3 opened this issue Mar 31, 2021 · 10 comments · Fixed by #17744
Assignees
Labels
Bug For errors / faults / flaws / inconsistencies etc. c: Privacy For issues that impact or improve the privacy.
Milestone

Comments

@Starker3
Copy link
Contributor

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
    image

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

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

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
Copy link
Member

tsteur commented Mar 31, 2021

@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
Copy link
Contributor Author

@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
Copy link
Member

tsteur commented Mar 31, 2021

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

image

@Starker3
Copy link
Contributor Author

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

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

@tsteur tsteur transferred this issue from matomo-org/tag-manager Mar 31, 2021
@tsteur
Copy link
Member

tsteur commented Mar 31, 2021

@Starker3 I moved it.

@Starker3
Copy link
Contributor Author

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)

@tsteur tsteur added Bug For errors / faults / flaws / inconsistencies etc. c: Privacy For issues that impact or improve the privacy. labels May 27, 2021
@Starker3
Copy link
Contributor Author

Reproducing issue with the standard JS tracker:

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

_paq.push(['requireCookieConsent']);
_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 tsteur added this to the 4.4.0 milestone May 28, 2021
@tsteur
Copy link
Member

tsteur commented May 28, 2021

@Starker3 thanks for this. moved it into 4.4

@justinvelluppillai justinvelluppillai self-assigned this Jul 5, 2021
@mattab mattab changed the title Setting cookie domain causing conflicts with Require Cookie Consent setting the cookie domain even when cookies are disabled, to avoid conflicts with Require Cookie Consent Jul 26, 2021
@mattab mattab changed the title setting the cookie domain even when cookies are disabled, to avoid conflicts with Require Cookie Consent setting the cookie domain even when cookies are disabled for compatibility with "Require Cookie Consent" feature Jul 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. c: Privacy For issues that impact or improve the privacy.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants