2 ms·
This is what we do. Store a 1st party httponly secure cookie jwt representing the user, then grab any extra data from the backend. Or just something like sessio
by dillondoyle 7y ago
This is what we do. Store a 1st party httponly secure cookie jwt representing the user, then grab any extra data from the backend. Or just something like session cookie but persist it.
I wouldn't be surprised if this is one of the ways ad tracking tries to rebuild a universal identifier like the old urchin module. Might not be as easy as a cname but those might get blocked. It's always a game of cat and mouse. Could place uuid as 1st party httponly cookie. maybe uuid is domain scoped. then 'echo out' so accessible by 3rd party JS. Like a hash, one would need to know the global pooled uuid already and then combined with knowable domain could tie that uuid into the 2nd party tracking pool.
- dfabulich 7y ago1st party httponly secure cookies will be erased in seven days. You need the user to manually provide an identifier (i.e. login) to avoid losing everything. The user's password safe is now the only non-volatile storage mechanism on Safari.
- johncolanduoni 7y agoThey explicitly say 1st party httponly secure cookies are exempt and are their first recommended alternative.
- shakna 7y ago> 1st party httponly secure cookies will be erased in seven days. httponly cookies can't be set from JS, and the seven day erasure only applies to cookies set from JS. That's why they're the recommended method for keeping a user logged in.