View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002140||Composr||core||public||2016-01-19 20:46||2019-11-14 22:05|
|Reporter||Chris Graham||Assigned To|
|Fixed in Version|
|Summary||0002140: User tracking system (to replace cookies)|
|Description||Let's consider some facts:|
1) Cookies suck. Users may disable them. The EU has a war against them. They take bandwidth for every HTTP request you make (so e.g. 100 requests on page, by 100 bytes of cookies = 10kb wasted transit, which is 1/20th of a second on 3g *if things are going well*). modsecurity may look at them and have a fit. Apache may just lock a client out if they have too much cookie data.
2) People move across multiple devices. Cookies are only on one device/browser only. Saving user data in cookies is not a good place to store it anymore.
3) However, we can't just stick stuff in member profiles because (a) we need to support other forums than our own [CPFs could be used though, but that's messy]) and (b) data needs to be saved for guests too.
4) We can't just stick stuff in sessions, because sessions are short-lived.
5) We can't just use local HTML storage because that's only client-side.
What we need is a "tracking profile" concept. It is essentially a long-lived session.
We need is two new tables...
The tracking profile ID (tracking_profile.id & tracking_data.d_profile_id) is alphanumeric and cryptographically random. It is stored as a long-term cookie on the user's browser. So we're not fully replacing cookies, we're using one master cookie as a key into something stored on-server.
tracking_profile.p_member_id may be null. But if a particular tracking profile ID logs in as a member, then either:
1) that ID gets assigned that member ID
2) the ID is deleted, with newer data (based on d_save_time) gets merged with the existing one (if appropriate). The pre-existing tracking profile ID is saved into the cookie. This essentially associates a new device with the existing tracking data.
There needs to be an API to manage this. A setter function, a getter function, Tempcode symbols for those functions, and an AJAX method for loading and saving the data,.
There need to be hooks to define which of the key's may not be set via AJAX (some might be non-user-editable).
It might be best to actually build this on top of our cookie API. We could call this "server-side cookies". The aforementioned hooks could determine the persistency method. The programmer therefore would not need to think about it.
The Code Book needs updating with documentation of this new system.
Composr Mobile SDK needs to be compatible with the new system - storing the new tracking profile cookie, and not storing the login cookies.
|Additional Information||All the following cookies can move over...|
The base configuration settings for cookie names would be best moved over to just specifying a "cookie prefix", just like the "table prefix".
|Tags||ocProducts client-work (likely), Type: Performance|
|Time estimation (hours)||10|