View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 2140 | Composr | core | public | 2016-01-19 20:46 | 2022-12-07 13:57 |
| Reporter | Chris Graham | Assigned To | Guest | ||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Summary | 2140: 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. They expire based on some fixed date in time, that cannot be read by JavaScript or server-side. 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 Information | All 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". | ||||
| Tags | ocProducts client-work (likely), Roadmap: Over the horizon, Type: Legal compliance / Privacy, Type: Performance | ||||
| Attach Tags | |||||
| Time estimation (hours) | 10 | ||||
| Sponsorship open | |||||
|
|
https://github.com/mikewest/http-state-tokens |
|
|
I defined this on a client site with thoughts about using it in the future... $GLOBALS['SITE_DB']->create_table('session_data', array( 's_session_id' => '*ID_TEXT', 's_key' => '*ID_TEXT', 's_val' => 'LONG_TEXT', )); function get_session_val($key) { return $GLOBALS['SITE_DB']->query_select_value_if_there('session_data', 's_val', array( 's_session_id' => get_session_id(true), 's_key' => $key, )); } function set_session_val($key, $val) { $GLOBALS['SITE_DB']->query_delete('session_data', array( 's_session_id' => get_session_id(true), 's_key' => $key, )); if ($val !== null) { $GLOBALS['SITE_DB']->query_insert('session_data', array( 's_session_id' => get_session_id(true), 's_key' => $key, 's_val' => $val, )); } } The query_delete/query_insert combo could be replaced with query_insert_or_replace in v11+. |
| 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 2672 |
| 2018-08-14 12:04 | Chris Graham | Note Added: 0005797 | |
| 2019-11-14 22:05 | Chris Graham | Tag Attached: ocProducts client-work (likely) | |
| 2020-05-27 19:57 | Chris Graham | Tag Attached: Roadmap: v12 | |
| 2021-03-14 21:23 | Chris Graham | Description Updated | |
| 2022-09-01 02:22 | Chris Graham | Tag Attached: Type: Legal compliance | |
| 2022-09-01 02:23 | Chris Graham | Tag Renamed | Type: Legal compliance => Type: Legal compliance / Privacy |
| 2022-09-01 02:24 | Chris Graham | Relationship added | related to 4914 |
| 2022-12-07 13:55 | Guest | Note Added: 0007781 | |
| 2022-12-07 13:57 | Chris Graham | Note Added: 0007782 | |
| 2024-03-26 00:58 | PDStig | Tag Renamed | Roadmap: v12 => Roadmap: Over the horizon |
