View Issue Details

IDProjectCategoryView StatusLast Update
0002140Composrcorepublic2019-11-14 22:05
ReporterChris GrahamAssigned To 
Severityfeature 
Status non-assignedResolutionopen 
Product Version 
Fixed in Version 
Summary0002140: User tracking system (to replace cookies)
DescriptionLet'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...

tracking_profile:
ID_TEXT id
?MEMBER p_member_id

tracking_data:
*ID_TEXT d_profile_id
*ID_TEXT d_key
LONG_TEXT d_value
TIME d_save_time

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 InformationAll the following cookies can move over...

commandr_*
cms_member_hash
cms_member_id
cms_member_id_invisible
cookieconsent_dismissed
has_referers
referrer
feed_*
has_cookies
software_chat_prefs
tray_*
use_wysiwyg


The base configuration settings for cookie names would be best moved over to just specifying a "cookie prefix", just like the "table prefix".
TagsocProducts client-work (likely), Type: Performance
Attach Tags
Time estimation (hours)10
Sponsorship open

Relationships

parent of 0002672 non-assigned Local caching of blocks 
Not all the children of this issue are yet resolved or closed.

Activities

Issue History

Date Modified Username Field Change
2016-06-15 00:16 Chris Graham Tag Attached: Type: Performance
2016-06-19 18:53 Chris Graham Relationship added parent of 0002672
2018-08-14 12:04 Chris Graham Note Added: 0005797
2019-11-14 22:05 Chris Graham Tag Attached: ocProducts client-work (likely)