@robocoder opened this issue on February 18th 2009

From discussion in http://forum.piwik.org/index.php?showtopic=217

Depends on: #409

@robocoder commented on February 22nd 2009

On second thought, this doesn't depend on 409, but the client (piwik.js) needs to know/reconstruct the 3rd party cookie name.

We do need #408 fixed (possibly in conjunction with this ticket).

A first party cookie set by the client is sent as a URL param, eg PK_FPC (we could have a default and allow it to be set, ala cookie_name on the server).

Since first- vs third-party depends on whether Piwik is hosted on the same domain as the site being tracked, I'll refer to the current implementation as "legacy cookies".

User stories: - Legacy client, New visitor: Server sets legacy cookie - Legacy client, Returning visitor: Client sends legacy cookie. Server reuses cookie. - New client, New visitor: Client sets FPC. Server adopts FPC. - New client, Returning Visitor: Client sets FPC and deletes (expires) legacy cookie. Server reuses FPC and clears the legacy cookie if received. (ie some browsers won't delete cookie until session has ended/browser closed).

Need to add documentation re: P3P policy for IE6+.

@robocoder commented on March 23rd 2009

Building on the new piwik.js, the implementation stalled on how the client would initialize the fpc (first time). Theoretically, we could implement the JavaScript equivalent of md5(uniqid(rand(), true)) /* i.e., idvisitor in the current cookie implementation */

See http://phpjs.org for JavaScript equivalents of various PHP functions.

Dependencies: - #408 allows the server to accept the client generated cookie and add it to the database. - #409 shortens the cookie to simply contain idvisitor

@mattab commented on June 3rd 2010

Rolling in the requirements of this ticket into #409

This issue was closed on January 10th 2011
Powered by GitHub Issue Mirror