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

optUserOut cookie expires after session #14487

Closed
Findus23 opened this issue May 27, 2019 · 7 comments · Fixed by #14674
Closed

optUserOut cookie expires after session #14487

Findus23 opened this issue May 27, 2019 · 7 comments · Fixed by #14674
Assignees
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Milestone

Comments

@Findus23
Copy link
Member

The cookie set by the new _paq.push(['optUserOut']) feature (mtm_consent_removed) seems to be only valid for a session due to setting 0 here:

setCookie(CONSENT_REMOVED_COOKIE_NAME, new Date().getTime(), 0, configCookiePath, configCookieDomain, configCookieIsSecure);

@Findus23 Findus23 added the Bug For errors / faults / flaws / inconsistencies etc. label May 27, 2019
@mattab mattab added this to the 3.11.0 milestone May 27, 2019
@mattab
Copy link
Member

mattab commented May 27, 2019

@tsteur
Copy link
Member

tsteur commented May 27, 2019

See docs

         * Calling this method will remove any previously given consent and during this page view no request
         * will be sent anymore ({@link requireConsent()}) will be called automatically to ensure the removed
         * consent will be enforced. You may call this method if the user removes consent manually, or if you
         * want to re-ask for consent after a specific time period.

that should be on purpose only during this page view or not?

@Findus23
Copy link
Member Author

@tsteur In that case I (and the help at https://developer.matomo.org/guides/tracking-javascript-guide#optional-creating-a-custom-opt-out-form) are misunderstanding the use case for that feature.

I was recommending to use optUserOut to people who had issues as their Matomo is on a different and therefore the opt-out iFrame isn't working as most browsers block third-party-cookies.
Also for people who wanted to customize the look of their opt-out more than it is possible with an iFrame.

The docs for optUserOut also seem to indicate this use case:

matomo/js/piwik.js

Lines 7538 to 7542 in 871c31d

/**
* Alias for forgetConsentGiven(). After calling this function, the user will no longer be tracked,
* (even if they come back to the site).
*/
this.optUserOut = this.forgetConsentGiven;

@tsteur
Copy link
Member

tsteur commented May 28, 2019

@Findus23 I don't really know how it is supposed to be used for user opt outs. The initial implementation was for consent and then some symlinks for userOptOut and forgetUserOptOut was added. Not sure how much these actually work. Maybe it was misunderstood how these methods behave when adding the symlinks.

For a custom opt out they can't really work I think since you would also need to "requireConsent" on every page load or so? Not sure.

@tsteur
Copy link
Member

tsteur commented Jul 18, 2019

@Findus23 is this issue maybe then only about updating the docs?

@wlabarron
Copy link

I’ve been trying to use this feature to create a custom opt-out form, because the one built into Matomo doesn’t work if you’re tracking sites over multiple domains (third-party cookie blockers are on by default in a few browsers now). If this cookie is a misunderstanding of the use case, perhaps the function shouldn’t be called “optUserOut” and the docs should be updated, and whatever opt-out cookie the built-in opt-out form sets should be exposed to users. My main issue at the moment is I have no reliable way for a user to opt out of tracking. Please excuse my ignorance if any of this is wrong, I’m a Matomo user and I’ve not contributed to the Matomo project before.

@tsteur
Copy link
Member

tsteur commented Jul 18, 2019

Looking at this PR 6f5b85b#diff-1279d666063b65e6d6777f902d11574fR7302 it was maybe meant to be stored forever the cookie? Or what life time should we set here? From what I see we would need to set like year 2030 as it can't be stored forever. If we can make this use case work by fixing the set cookie to store it forever, I reckon we should.

Mozilla actually suggests setting document.cookie = "someCookieName=true; expires=Fri, 31 Dec 9999 23:59:59 GMT"; :) https://developer.mozilla.org/en-US/docs/Web/API/document/cookie

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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants