XF 2.0 Downsides to excessive use of cookies?

[Jaxel]

You guys think there is a downside in excessive uses of cookies?

I've got a filtering system in one of my addons, where the filter options are stored in cookies. In the old version, I stored it in a DB table.

 

[CyberAP]

Cookies are sent with each request, event if they're not needed. I'd use Local Storage for that purpose and depending on how you retrieve that page send this data through JSON or GET\POST request body.
If you don't need to store that data, using just request string would be fine I think (and even better if these URLs can be shared). Exactly like XF2 does it with filters.

 

[Jaxel]

I didn't want to use request string, because I wanted the data to be saved across the session.

I'm using cookies instead of local storage, because of server side interactions. Its my understanding that local storage is only for client side stuff.

 

[Jake B.]

You can probably assign the data to the user's session instead if you want it to be kept. Will probably be cleaner than cookies as well

 

[Jaxel]

You can probably assign the data to the user's session instead if you want it to be kept. Will probably be cleaner than cookies as well

Explain pls?

 

[CyberAP]

Explain pls?

That probably means that you don't store anything on a client but instead do it all on the server-side tracked by user_id.

 

[Mike]

He actually meant storing the data in the session on the server side, which is a bit different from storing it somewhere else that's tracked by user ID. The latter would be good if you are targeting a permanent default preference type thing (like the what's new filter system). In the session would be good if it really is just a default for this particular session.

 

[Jake B.]

Explain pls?

Have a look at \XF::app()->getSession() and the methods available within it. You can use this if you want it to be used while the user is logged in on a specific device (until they log out, clear cookies, or otherwise generate a new session), but if you want it to persist across sessions and between devices for a user doing what XF does for the what's new filter would be the way to go probably.

You could also use LocalStorage, but you can't directly load that from PHP so you'd need javascript to interface with it

 

[Jaxel]

How do I use these sessions? \XF::app()->getSession() doesnt exist...

And what advantages would using sessions have over using non-persistent cookies?

 

[Paul R]

$session = $this->session();
$sessionData= $session->get('sessionname');

 

[Jaxel]

$session = $this->session();
$sessionData= $session->get('sessionname');

Got it! Thanks... But again, why use this instead of cookies?

 

[Jake B.]

Cookies are sent with every request regardless of whether it's needed or not. Obviously it's not going to add that much extra data, but the XenForo session is controlled via a cookie already, and this stores it within your database for that specific session so you'll have more control over it (for example, they can't just randomly delete a cookie and potentially break something -- they'd just get logged out of XenForo)

Also, if someone were using an add-on to prevent cookies from being applied before they were accepted to conform with EU laws this would automatically work with it since it's only using XenForo's default session cookie

 

[Jaxel]

Yeah... thats true. I was thinking about the extra work involved in sanitizing these cookies if someone started messing around with things.